This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]