newnfs client and statfs

[Bruce Evans]

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