where do %j/uintmax_t stand in terms of standards? [WAS: Re: WARNS cleanup for ipfw

[Maxime Henrion]

Maxime Henrion wrote:
> Luigi Rizzo wrote:
> > On Sun, Mar 07, 2004 at 12:30:08PM +0100, Johan Karlsson wrote:
> > ...
> > > Ok, how about the attached patch then? It takes care of all printf
> > > related warnings on -current.
> > 
> > not there yet, sorry...
> > 
> > No offense, but I think that rather than rushing for a commit you
> > should wait a few days to get some feedback from people using 64-bit
> > platforms (e.g.  try to post to -sparc or -alpha, or ask some of
> > the people involved with 64-bit development), and also have a look
> > at how other system utilities deal with similar things (64-bit
> > counters and possible alignment problems -- what is the preferred
> > way to print out things, "%qu" or "%llu" ? I understand that
> > ipfw2.c does a mix of both things, i just have no idea which one is
> > better except that "unsigned long long" is a lot longer to
> > write than "u_quad_t" so that might favour "%qu" ?).
> > In any case, it's a weekend, give people a bit of time to read and
> > think about solutions.
> 
> The "%llu" format is preferred over "%qu", because the latter is
> BSD-specific while the former is in C99 now (it was a GCC extension
> before).  It is correct to cast to unsigned long long and use "%llu" to
> print an uint64_t because a long long is guaranteed to always be at
> least 64 bits.  One should however still use uint64_t to store the type
> rather than unsigned long long because it may be bigger than 64 bits.
> So unsigned long long should only be used for the cast here.

Replying to myself : it's interesting to know that C99 introduces some
macros expanding to printf() formats.  Those are in inttypes.h.  For
instance, to print an uint64_t, one should theoritically use the PRIu64
macro, ie: `` printf("%" PRIu64 "\n", foo); ''.  We actually don't use
those in FreeBSD because they are simply ugly.  Also, it's probably not
a good idea to use this in ipfw since Luigi is concerned about keeping
the code similar in 5.x and 4.x.

Cheers,
Maxime