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

Corinna Vinschen <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
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
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIyBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAls+E7wACgkQ9TYGna5E
T6AYBQ/1GIZjoJuzKUb/rSQYdYg6Gz+PKReFUGq2zzDElqnRH1Rot01dIJr0RJdu
ljxVmSphk9eAdCxanIQbts1k8yioPdgDGSjtjrnfic8rXm6c6JorpS7tKqy8ksd/
s0uP8sMmPUY6uasnA4LZMVgLOlKvQWLvWzaRA9AdIz7oOsnwLo+TqqGCbPZfV72z
wz2Fiyr4NW6Z4HkZxn4kYAmiAd7Pa+020IYs1Lf4AbaasDP6JhU9m4ACJVXUroE9
CgvYbdOTgAn5e53WfLNjxcH/R4Yt0QL0RYfPC4Pd627pwE1+1RkkPbOngh/GMMuP
k4OE+QjUmoS4tHsp4MYRvjNgYRTOeJdjBqh7mrkDDKw++abnqXDy52Z4ZX/bzPPe
XTYi2P20Z5CpGqYjz42U4d/embZdyeQ0b1sQuHBxR4YG5sBSQ4bz7EckqDZLOIeg
eUsA/u6Zyz1ex7hBM/AFrTGT3bYL0TcI6BFin2PY/yYaTF8PY9Mbw8UUs4TC8Koz
dTT4Lhb/xMRYACadqCrIyk8bWzfgEb+6XY4D4NJMvVqIIx82INPyrGAZFRmSGy88
qy0HXOdUVVkPbvXZALmH9znM02hxVhzNWncaQjb/S4I3XmrYISnz+guIoOBaixR9
umxgh7YffSh9LU9VwAnvuFa0HHREmE7+5+7QTdrCY4gMJG+5Aw==
=yU+0
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.