Date: Mon, 20 Jan 2003 10:48:25 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: "M. Warner Losh" <imp@bsdimp.com> Cc: jmallett@FreeBSD.org, <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/sbin/dumpfs dumpfs.c Message-ID: <20030120103433.Y21079-100000@gamplex.bde.org> In-Reply-To: <20030119.133145.02779620.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 19 Jan 2003, M. Warner Losh wrote: > In message: <200301191213.h0JCDlRT025151@repoman.freebsd.org> > Juli Mallett <jmallett@FreeBSD.org> writes: > : XXX Lots of this assumes int32 can be printed with %d. Yuck. > > Why is that a problem? If int is 32bits, it is right. If int is 64 > bits, it will be promoted to 64 bit in before being passed. Either > way it is right. > > It fails in the int is 16 bit case, but who cares about that? Only C programmers. It also fails in the int is 17-31 bit cases, and on systems where longs are 32 bits and int32_t happens to be implemented as long. Note that in 4.4BSDLite1, most of the int32_t fields in <ufs/ffs/fs.h>. They were changed to int32_t in 4.4BSDLite2, but the formats used to print them haven't changed. gcc -Wformat would have detected the format mismatches in Lite1 but now happens not to notice because of the implementation details of int32_t. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030120103433.Y21079-100000>