Re: fwrite() - possible division by zero

[Geraldo Netto <geraldonetto@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]

Hello Guys,

Thanks for your support/assistance and my apologies for the trouble
I'm trying to learn more about musl to upgrade musl version on osv
But as you could notice, i'm completely newbie in this, oops!

Anyway, let's keep in touch


Kind Regards,

Geraldo Netto
Sapere Aude => Non dvcor, dvco
http://exdev.sf.net/

On 15 February 2018 at 02:20, Rich Felker <dalias@libc.org> wrote:

> 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
>

[-- Attachment #2: Type: text/html, Size: 4086 bytes --]