Re: fread, fwrite with size 0

[Rich Felker <dalias@libc.org>]

On Wed, Feb 10, 2016 at 07:42:34PM -0500, Rich Felker wrote:
> On Wed, Feb 03, 2016 at 11:39:48PM -0500, Rich Felker wrote:
> > On Wed, Feb 03, 2016 at 09:53:21AM +0100, hombre wrote:
> > > Hello,
> > > 
> > > I think that fread and fwrite does not return 0 when parameter size
> > > is 0 (when nmemb is 0, it does).
> > > Clib spec says: If size or nmemb is zero, fread/fwrite returns zero
> > > 
> > > I did the following changes to make it work:
> > > 
> > > fread:
> > > from
> > >     return nmemb;
> > > to
> > >     return len == 0 ? 0 : nmemb;
> > > 
> > > fwrite:
> > > from
> > >     return k == l ? nmemb : k / size;
> > > to
> > >     if (l == 0)
> > >         return 0;
> > >     else
> > >         return k == l ? nmemb : k / size;
> > > 
> > > Regards,
> > > Erwin
> > 
> > Thanks. Sadly the POSIX version of the text is contradictory on this:
> > 
> > "Upon successful completion, fread() shall return the number of
> > elements successfully read which is less than nitems only if a read
> > error or end-of-file is encountered. If size or nitems is 0, fread()
> > shall return 0 and the contents of the array and the state of the
> > stream remain unchanged."
> > 
> > First it says that the return value can be less than nitems only if an
> > error of EOF happens, but then it gives another way the return value
> > can be less than nitems (if size is 0).
> > 
> > Fortunately the ISO C text is not so broken and agrees with you:
> > 
> > "The fread function returns the number of elements successfully read,
> > which may be less than nmemb if a read error or end-of-file is
> > encountered. If size or nmemb is zero, fread returns zero and the
> > contents of the array and the state of the stream remain unchanged."
> > 
> > There's another issue I want to fix here too, but I might do it in two
> > commits. Thanks for the report.
> 
> I'm fixing this by adding:
> 
> 	if (!size) nmemb = 0;
> 
> to the top of both functions. This is preferable because, at least for
> fread, I'm also going to have to check for nmemb>=SIZE_MAX/size in
> order to properly handle this case (see glibc bug 19165), and having
> already ruled out size==0 (i.e. only doing the overflow check in the
> 'else' path for the above 'if') makes that division safe.

I'm going to hold off on doing anything about the latter issue
(overflow/saturating mul) because the kernel is not even able to
handle these read requests correctly, so we would not get any
immediate correctness 'benefit' anyway without lots of hacks to work
around the kernel's [mis?]behavior. But the size==0 case should be
working correctly now.

Rich