From owner-freebsd-fs@FreeBSD.ORG Sun May 1 18:12:51 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A18D2106564A; Sun, 1 May 2011 18:12:51 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id 4098B8FC14; Sun, 1 May 2011 18:12:50 +0000 (UTC) Received: from c122-106-155-58.carlnfd1.nsw.optusnet.com.au (c122-106-155-58.carlnfd1.nsw.optusnet.com.au [122.106.155.58]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p41IClBc016305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 May 2011 04:12:49 +1000 Date: Mon, 2 May 2011 04:12:47 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Rick Macklem In-Reply-To: <1211771823.830180.1304268292625.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: <20110502035720.F2645@besplex.bde.org> References: <1211771823.830180.1304268292625.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: rmacklem@freebsd.org, fs@freebsd.org Subject: Re: newnfs client and statfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 18:12:51 -0000 On Sun, 1 May 2011, Rick Macklem wrote: >> UINT64_MAX, etc., are defined in , which doesn't even >> need >> to be included explicitly, since it is (bogusly) standard namespace >> pollution in . This namespace pollution gives the bizarre >> ... > Ok, now I see them (in machine/include/_stdint.h). Appologies for the > noise. I grep'd sys/sys and couldn't find anything called (U)INT64_MAX. > > Now, remembering that sf_abytes is uint64_t per the RFCs, what do people > think of either of these? > > if (sfp->sf_abytes > INT64_MAX) > sbp->f_bavail = INT64_MAX; > else > sbp->f_bavail = sfp->sf_abytes / NFS_FABLKSIZE; You don't need to do anything at runtime, since everything is 64 bits and f_bavail is a block count while sf_abytes is a byte count. 1 bit is lost to the sign bit in f_bavail, but 9 bits are gained by scaling by NFS_FABLKSIZE, leaving 8 bits to spare. Calculating the limit at runtime would give INT64_MAX / NFS_FABSBLKSIZE, or perhaps 1 more than that (to round up instead of down). You might still want to use an out-of-band limit like INT64_MAX for technical reasons, but that risks more bugs (for example, anything converting INT64_MAX / NFS_FABSBLKSIZE + 1 "back" to a byte count would overflow and anything converting INT64_MAX "back" to a byte count would overflow even uint64_t. > Or should I try and do the division to see if the large > value in sf_abytes will fit in INT64_MAX after the division? Something > like: Runtime tests have the advantage of continuing to work if someone changes the types, provided they are robust, but making them robust is too hard here. Robust test's can't simply use INT64_MAX, since INT64_MAX is only the max if the type is int64_t... Bruce