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

[Brian Inglis]

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.)
> Â Â Â Â  It is a bad solution from the point of view that the C standard (C11 N1570
> 7.21.10.4#2) says that perror() "writes a sequence of characters to the standard
> error stream".  That is, using write does not write to the stream, itself, as
> required.  So the question becomes, is this a real problem, or only a
> theoretical problem? Since write ultimately is called for writes to the stream,
> how real of a problem is it?  As already noted, there is one settings case
> (fully buffered) in which actual behavior could be different.
> Â  Â Â  I think that one way of quantifying the general problem is that we have a
> choice between 3 options. Â  1) violate a POSIX CX extension (present state), 2)Â 
> remain strictly C and POSIX CX compliant (which the present thread has
> characterized as making the code a lot more complicated), or 3) violate the C
> standard (albeit in a way that can be argued to be meaningless).
> Â Â Â Â  (To be very picky, the preceding evaluations as to how settings might
> affect output are based on using newlib as it stands. Obviously, if anyone has
> partially "hacked" the stream method for efficiency purposes, things would
> differ more.  But this is an inherent danger in such edits, and should be
> understood as a risk by anyone who does them.  (I have done such in the past in
> highly-constrained systems, but I knew I might be stuck at a specific newlib
> version when I did so.))

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

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada