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

On 2018-07-03 07:21, Corinna Vinschen wrote:
> 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".

WG14 can only document as standard what is commonly implemented that will not
get a veto from Intl. Old Crufty Compiler Co. lobbying their ISO C country rep,
who may work for them, or a government dept. using their products.

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

Pity 64 bit was not ubiquious earlier so 32 bit wide chars became standard and
nobody got the idea that a 16 bit wide char internal format should be used for
text I/O ;^>

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