Date: Sat, 6 Mar 2004 12:53:23 +0100 (CET) From: Lukas Ertl <le@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: bin/62536: df gives insane numbers when using root-reserved space Message-ID: <20040306125229.W671@korben.in.tern> In-Reply-To: <20040306205848.A8077@gamplex.bde.org> References: <200403051548.i25Fmmsa073994@freefall.freebsd.org> <20040306094559.F614@korben.in.tern> <20040306205848.A8077@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 6 Mar 2004, Bruce Evans wrote: > On Sat, 6 Mar 2004, Lukas Ertl wrote: > > > On Sat, 6 Mar 2004, Kris Kennaway wrote: > > > > > On Fri, Mar 05, 2004 at 07:48:48AM -0800, Lukas Ertl wrote: > > > > Synopsis: df gives insane numbers when using root-reserved space > > > > .. > > > > Responsible-Changed-Why: > > > > I probably have a fix for this. > > > > > > pjd has a patch for this as well..I haven't yet tested it. > > I discussed this bug with Ian Dowse. As pointed out in my review of the > statfs changes, using unsigned types just asks for bugs like this. What > chance has the average consumer of statfs avoiding these bugs when its > primary consumer (df) gets almost related to the larger sizes and signed > types wrong despite being adjusted for the statfs changes? > > > Index: bin/df/df.c > > =================================================================== > > RCS file: /home/ncvs/src/bin/df/df.c,v > > retrieving revision 1.55 > > diff -u -r1.55 df.c > > --- bin/df/df.c 5 Mar 2004 08:10:16 -0000 1.55 > > +++ bin/df/df.c 5 Mar 2004 15:51:00 -0000 > > @@ -400,7 +400,8 @@ > > */ > > #define fsbtoblk(num, fsbs, bs) \ > > (((fsbs) != 0 && (fsbs) < (bs)) ? \ > > - (num) / ((bs) / (fsbs)) : (num) * ((fsbs) / (bs))) > > + (num) / (int64_t)((bs) / (fsbs)) : \ > > + (num) * (int64_t)((fsbs) / (bs))) > > > > /* > > I use this with intmax_t instead of int64_t. Such casts are bogus, however, > Block sizes are now (bogusly) unsigned, and sometimes 64 bits too. Casts > like the above only work if the the original types really are bogus. If > all the bits of uint64_t were actually needed to hold block sizes, then the > casts would just truncate the values. The truncation is done blindly. OK, so should I go and commit this patch (with intmax_t instead of int64_t)? regards, le -- Lukas Ertl http://mailbox.univie.ac.at/~le/ le@FreeBSD.org http://people.freebsd.org/~le/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040306125229.W671>