cvs commit: src/sys/net if_ethersubr.c src/sys/sys mbuf.h src/sys/kern uipc_mbuf.c src/sys/conf NOTES options

[Bruce Evans]

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