Date: Thu, 1 May 2008 12:35:59 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Marcel Moolenaar <xcllnt@mac.com> Cc: src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, Julian Elischer <julian@elischer.org>, Max Laier <max@love2party.net>, Julian Elischer <julian@freebsd.org> Subject: Re: cvs commit: src/sys/net if_ethersubr.c src/sys/sys mbuf.h src/sys/kern uipc_mbuf.c src/sys/conf NOTES options Message-ID: <20080501114438.P93336@delplex.bde.org> In-Reply-To: <42F8226A-A63D-44AB-8BF7-A74233520F24@mac.com> References: <200804292123.m3TLNLwT044155@repoman.freebsd.org> <200804301939.06987.max@love2party.net> <4818BCEF.1040308@elischer.org> <42F8226A-A63D-44AB-8BF7-A74233520F24@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 30 Apr 2008, Marcel Moolenaar wrote: > > On Apr 30, 2008, at 11:39 AM, Julian Elischer wrote: > >> Max Laier wrote: >>> On Tuesday 29 April 2008 23:23:21 Julian Elischer wrote: >>>> julian 2008-04-29 21:23:21 UTC >>>> ... >>>> Add an option (compiled out by default) >>>> to profile outoing packets for a number of mbuf chain >>>> related parameters >>>> e.g. number of mbufs, wasted space. >>>> probably will do with further work later. >>> This breaks the build: >>> http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.brief >>> 1) Use %u to print unsigned values >>> 2) printing [u]int64_t's has been broken since the beginning. The reason >>> is the unfortunate choice to have int64_t be a "long int" alias on >>> platforms with a 64bit long (while they could as easily be "long long int" >>> as on the other platforms where long is 32bit wide - this also means that >>> "long long" is > intmax_t which is an alias for int64_t). Hence you >>> either have to use the (ugly) PRIu64 macro, or %ju and cast to uintmax_t. >>> This is a no-op (as long as we don't have uint128_t or the like). >> >> I'm happy to change the types to any way you suggest.. >> how about just changing them to long long? This would be wrong. They ([u]intmax_t) are partly intentionally implemented as being different from long long iff this is possible (i.e., on arches with long the physically longest integral type), so that bad code is rewarded with printf format errors like the above. (Unfortunately, C's type checking is too weak to give stronger rewards.) Bad code does things like assuming that int64_t or long long is the longest type, or that these types are the same, or that int64_t is the same as long (rare) or int (rarer, partly because attempts to print int64_t's using %d would fail under almost all implementations). > I hope you don't mean redefining [u]int64_t from [u_]long to > [u_]long_long on 64-bit platforms? I violently oppose that. > > Itanium already supports 128-bit atomic operations and I like > like to keep long long available for that... I unviolently oppose that :-). The existence of long long is a bug. > Not to mention that PRIu64 is defined exactly for this issue, > so I would suggest that people get over their eye-of-beholder > objections and just use it (if casting to long long and sing > %llu is not an option)... The existence of PRI* is a bug. Casting to long long and sing (sic) %llu is not an option. Just convert to a larger standard type of the same signedness -- usually intmax_t or uintmax_t, since it is hard to figure out the minimal larger type even using ugly macros like PRI*. It can be hard to figure out the signedness even for casting to [u]intmax_t. PRI* provides no help for this -- you have to decide the 'u' at write time for both. PRI* also provides no help if the original type is not known, which is the usual case since most types should be typedefs. PRI* provides negative help if the original type is known now but changes -- then PRI* is too easy to use, but it breaks or starts working accidentally when the type changes. Conversions to [u]intmax_t keep working for all changes of the type except ones that change the signedness or the integrality. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080501114438.P93336>