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

[Corinna Vinschen <vinschen at redhat dot com>]

On Jul  2 10:40, Brian Inglis wrote:
> On 2018-07-02 09:46, Craig Howland wrote:
> > On 07/02/2018 07:36 AM, Eric Blake wrote:
> >> On 07/02/2018 05:28 AM, Corinna Vinschen wrote:
> >>>> By the way, I have noticed that psignal() and psiginfo() also have the
> >>>> same problem. psignal() belongs to newlib, so the same strategy can
> >>>> be applied. However, what can we do for psiginfo()? Only the FreeBSD
> >>>> route may be the answer...
> >>> I guess the simplest solution is to use the FreeBSD/OpenBSD method
> >>> all the time.
> >> If nothing else, it at least would mean fewer variations in practice,
> >> regardless of whether POSIX is changed to relax things (the POSIX discussion
> >> has been started, but it may be a while before any conclusion is reached;
> >> what's more, the C99 standard tried to address it in TC2
> >> (http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_276.htm) but then withdrew
> >> that in TC3 because the attempted resolution conflicted with the POSIX wording
> >> (http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_322.htm).
> >      To make it explicit, as looking back in the thread I don't see it stated
> > directly:  The FreeBSD/OpenBSD method is for perror()/psignal()/psiginfo() to
> > use write() to the stderr file number.  Supporting this as perhaps a good way to
> > go, the discussion thread on POSIX has pointed out that "the historic [perror()]
> > implementation calls write(2) to STDERR_FILENO."
> >      This sounds like a good solution for newlib from the points of view of 1)
> > staying small and uncomplicated, 2) producing behavior consistent with
> > historical systems, 3) not changing the stream orientation.  If does have a
> > potential drawback of possibly changing behavior since it would effectively mix
> > stream and write output from the application level whereas now it is only
> > stream.  On the other hand, since perror() does print a complete line, the
> > behavior should not change if the stream is either unbuffered or line buffered,
> > but could be different only if fully buffered.  However, the since stderr
> > default "is not fully buffered", the number of applications affected would
> > probably be in the minority.  (A subjective statement, but I expect it would be
> > very hard to quantify.)
> > [...]
> 
> DR 322 says:
> "Committee Discussion (for history only)
> 
> The Committee discussed making the behavior undefined, which would allow
> perror() to fail if the stream orientation has already been set to wide.
> 
> The proposed TC will permit (but not require) perror to set the orientation of
> an un-oriented stderr to narrow, and has what C calls undefined behavior if
> stderr was previously set to wide. This permits the POSIX required behavior."

I'm not overly sympathetic with this approach.  It opens up the standard
in a way which basically means, we allow any existing implementation to
claim standard compliance.

The side-effect is that now applications may have to worry about the 
orientation when usingg perror, not quite as, but similar to the
description in http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_322.htm
I'd rather see a better defense of the "don't change orientation".

Either way, to be on the safe side I think we should really do what
FreeBSD/OpenBSD (and Linux, just differently) are doing.

All interested parties ok with that?  If so, I think Takashi's patch can
go in.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature