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

Luigi Rizzo rizzo at icir.org
Sat Mar 6 21:22:34 PST 2004


On Sat, Mar 06, 2004 at 06:32:19PM +0100, Johan Karlsson wrote:
> [lets move this from ipfw@ to standars@ to get an answer]
> 
> 
> On Sat, Mar 06, 2004 at 08:26 (-0800) +0000, Luigi Rizzo wrote:
> > On Sat, Mar 06, 2004 at 12:19:22PM +0100, Johan Karlsson wrote:
> > > Hi
> > > 
> > > the attached patch makes ipfw WARNS=2 clean by using the
> > > %j/(uintmax_t) combo where so needed. If there are no
> > > objections I intend to commit this patch.
> 
> First of all, %j/uintmax_t is used since uint64_t does not match
> long long on all our platforms. Hence to print this without warning
> we need to do this.

ok, given that our counters _are_ 64 bits on all platforms, and
that it would be nice to use the same code on 4.x and 5.x (at least,
I'd hate to see a large number of differences for something trivial
as a printf specifier), i suggest to leave the print format as "%llu",
which is supported on all versions and platforms, and change
align_uint64() as following:

-static __inline uint64_t
+static unsigned long long
 align_uint64(uint64_t *pll) {
	uint64_t ret;

+	/* make sure the value is correctly aligned, as pll might be not */
	bcopy (pll, &ret, sizeof(ret));
-	return ret;
+	return (unsigned long long)ret;
 };

(we do not care about __inline since this is always called 
within a *printf() which is way more expensive).
This should close the issue, and is a lot more readable and
portable than the proposed patch or my previous suggestion.

	cheers
	luigi


More information about the freebsd-ipfw mailing list