Date: Tue, 20 Apr 2010 19:39:14 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: Luigi Rizzo <luigi@FreeBSD.org>, src-committers@FreeBSD.org, Robert Noland <rnoland@FreeBSD.org>, svn-src-all@FreeBSD.org, Julian Elischer <julian@elischer.org>, svn-src-head@FreeBSD.org Subject: Re: svn commit: r206843 - head/sbin/ipfw Message-ID: <20100420192603.R4920@delplex.bde.org> In-Reply-To: <20100420054227.GA62058@onelab2.iet.unipi.it> References: <201004191511.o3JFBjLj036350@svn.freebsd.org> <4BCC7E64.4040200@FreeBSD.org> <4BCCDCC9.2070604@elischer.org> <20100420054227.GA62058@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Apr 2010, Luigi Rizzo wrote: > On Mon, Apr 19, 2010 at 03:44:25PM -0700, Julian Elischer wrote: >> On 4/19/10 9:01 AM, Robert Noland wrote: >>> >>> >>> Luigi Rizzo wrote: >> >> >> [...] >> >>> Index: sbin/ipfw/ipfw2.c >>> =================================================================== >>> --- sbin/ipfw/ipfw2.c (revision 206844) >>> +++ sbin/ipfw/ipfw2.c (working copy) >>> @@ -326,7 +326,7 @@ >>> #ifdef TCC >>> #define U64_FMT "I64" >>> #else >>> -#define U64_FMT "llu" >>> +#define U64_FMT "ju" >>> #endif >>> uint64_t d; Ugh. I started introducing intmax_t about 10 years ago to try to kill long long. But long long is now used much more than 10 years ago :-(. Also, uint64_t should not be used in contexts like this (where hardware requirements don't require any particular size). >> believe there is a posix define for this? >> (though I can't remember it right now). Nothing to do with POSIX. The C99 define for this even less portable than the above (though easier to fake in header files). All of the above basically require C99. > the reason for the above code is that MSVC (actually, the DLL in > Windows -- so the problem exists also for TCC on Windows) does not > support %llu or %ju but only %I64 and that is why i need this ugly > code (to tell the truth i am not even sure that the various libc > for embedded platforms support %ju). All FreeBSD libc's should, since %ju is part of the small part of C99 actually supported by FreeBSD. For a vendor embedded platform, support depends on the vendor having the sam support for C99 as FreeBSD does in this area. %I64 is actually better than the C99 formats, though not as good as %IDWIM where the compiler rewrites the format string, replacing %IDWIM by any C99 or vendor format specifier that will work at runtime (only works for literal format strings). I think %I is in sfio, where this and other design errors in stdio were fixed long before C99 standardized more errors. Don't know if sfio has %IDWIM -- this requires compiler support. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100420192603.R4920>