[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACJ51z0p382Vr2aoqh8H8_BLnyz2Bn0vzahYgmX9Z2cDVW7Phg@mail.gmail.com>
Date: Wed, 14 Feb 2018 16:47:46 -0500
From: Andrew Bell <andrew.bell.ia@...il.com>
To: musl@...ts.openwall.com
Subject: Re: fwrite() - possible division by zero
On Wed, Feb 14, 2018 at 4:15 PM, Szabolcs Nagy <nsz@...t70.net> wrote:
> * Andrew Bell <andrew.bell.ia@...il.com> [2018-02-14 15:11:34 -0500]:
> > On Wed, Feb 14, 2018 at 3:07 PM, Markus Wichmann <nullplan@....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.
Best,
--
Andrew Bell
andrew.bell.ia@...il.com
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
