Re: fwrite() - possible division by zero

[Rich Felker <dalias@libc.org>]

On Wed, Feb 14, 2018 at 04:47:46PM -0500, Andrew Bell wrote:
> On Wed, Feb 14, 2018 at 4:15 PM, Szabolcs Nagy <nsz@port70.net> wrote:
> 
> > * Andrew Bell <andrew.bell.ia@gmail.com> [2018-02-14 15:11:34 -0500]:
> > > On Wed, Feb 14, 2018 at 3:07 PM, Markus Wichmann <nullplan@gmx.net>
> > wrote:
> > >
> > > > On Wed, Feb 14, 2018 at 02:48:14PM -0500, Andrew Bell wrote:
> > > > > Why not early return if size == 0 and avoid the call to __fwritex
> > > > > altogether?
> > > > >
> > > >
> > > > Because it's a rare corner case? Here, there's also locking correctness
> > > > to consider: fwrite() has to block until f is unlocked, irrespective of
> > > > parameters. So there's no real benefit to doing an early return.
> > > >
> > >
> > > But it's already being checked to set nmemb to 0.  Couldn't you just
> > return
> > > 0 and avoid the lock as well?
> >
> > the lock must not be avoided.
> >
> > otherwise fwrite would make progress on a FILE locked by
> > another thread which is non-conforming.
> 
> 
> That's not how I read this: http://port70.net/~nsz/c/c11/n1570.html#7.21.2p8
> 
> "All functions that read, write, position, or query the position of a
> stream lock the stream before accessing it.
> They release the lock associated with the stream when the access is
> complete."
> 
> When size == 0, the FILE doesn't need to be accessed so no lock should be
> necessary.
> Perhaps language of this document has been superseded?
> 
> But it doesn't much matter.  It just seemed to make the code more clear to
> me and would have avoided the initial question.

It's a POSIX requirement:

	"All functions that reference (FILE *) objects, except those
	with names ending in _unlocked, shall behave as if they use
	flockfile() and funlockfile() internally to obtain ownership
	of these (FILE *) objects."

http://pubs.opengroup.org/onlinepubs/9699919799/functions/flockfile.html

Rich