perror() changes the orientation of stderr to byte-oriented mode if stderr is not oriented yet.

[Corinna Vinschen]

On Jul  5 20:35, Takashi Yano wrote:
> Hi Corinna,
> 
> Thank you for checking.
> 
> On Thu, 5 Jul 2018 13:19:21 +0200
> Corinna Vinschen wrote:
> > Yes, we need it, the entire operation, flushing and writing, must be
> > cancel-safe and synchronized with other access to the stderr FILE.
> > 
> > Comparing with FreeBSD, there's also something missing.  After the
> > write operation, the offset in the FILE structure is incorrect.
> > Consequentially the __SOFF flag is reset to 0 last thing before
> > unlocking the file:
> > 
> >   stderr->_flags &= ~__SOFF;
> 
> Do you mean these are necessary for both perror.c and psignal.c?
> How about psiginfo() case?

Well, as long as we use the method at hand, I think it's the right thing
to do.  However...

...I noticed that FreeBSD handles psignal differently.  It writes the
output immediately to STDERR_FILENO, rather than to stderr or
fileno(stderr).  It does also not call fflush or reset the _SOFF flag.

OpenBSD uses this method for perror as well, no syncing with stderr,
no cancel-safety.

GLibc duplicates the file descriptor in perror, but writes immediately
to STDERR_FILENO in psiginfo, or uses an internal variation of
fprintf in psignal (thus potentially changing the orientation).

Ok, I'm a bit more puzzled than before.  What all this is missing is
*consistency*.

I really wonder how standards-compliant this is.  For all three
functions POSIX says something like "... shall print a message out on
stderr ...".  stderr is the stream and it's underlying descriptor, not
necessarily STDERR_FILENO.

If immediate writing to STDERR_FILENO is ok, we should simply call
write(STDERR_FILENO) and be done with it.  Just like BSDs and Linux,
we don't even have to loop until all bytes have been written, none
of the above does.


Thoughts?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20180705/96e2abeb/attachment.sig>