From owner-freebsd-bugs@FreeBSD.ORG Sat Mar 6 03:53:41 2004 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F4D716A4CE; Sat, 6 Mar 2004 03:53:41 -0800 (PST) Received: from mailbox.univie.ac.at (mailbox.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 651D343D41; Sat, 6 Mar 2004 03:53:40 -0800 (PST) (envelope-from le@FreeBSD.org) Received: from wireless (adslle.cc.univie.ac.at [131.130.102.11]) i26BrNqK1330796; Sat, 6 Mar 2004 12:53:31 +0100 Date: Sat, 6 Mar 2004 12:53:23 +0100 (CET) From: Lukas Ertl To: Bruce Evans In-Reply-To: <20040306205848.A8077@gamplex.bde.org> Message-ID: <20040306125229.W671@korben.in.tern> References: <200403051548.i25Fmmsa073994@freefall.freebsd.org> <20040306094559.F614@korben.in.tern> <20040306205848.A8077@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-DCC-ZID-Univie-Metrics: mailbox 4246; Body=0 Fuz1=0 Fuz2=0 cc: grog@FreeBSD.org cc: freebsd-bugs@FreeBSD.org cc: pjd@FreeBSD.org cc: Kris Kennaway Subject: Re: bin/62536: df gives insane numbers when using root-reserved space X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2004 11:53:41 -0000 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/