Date: Mon, 2 May 2011 04:12:47 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: rmacklem@freebsd.org, fs@freebsd.org Subject: Re: newnfs client and statfs Message-ID: <20110502035720.F2645@besplex.bde.org> In-Reply-To: <1211771823.830180.1304268292625.JavaMail.root@erie.cs.uoguelph.ca> References: <1211771823.830180.1304268292625.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 1 May 2011, Rick Macklem wrote: >> UINT64_MAX, etc., are defined in <sys/stdint.h>, which doesn't even >> need >> to be included explicitly, since it is (bogusly) standard namespace >> pollution in <sys/systm.h>. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110502035720.F2645>