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