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

On 06/28/2018 01:54 PM, Brian Inglis wrote:
> On 2018-06-28 10:28, Craig Howland wrote:
>> On 06/27/2018 08:55 AM, Corinna Vinschen wrote:
>>> On Jun 27 20:01, Takashi Yano wrote:
>>>> POSIX states:
>>>> The perror() function shall not change the orientation of the standard
>>>> error stream.
>>>> However, cygwin perror() function changes the orientation of stderr to
>>>> byte-oriented mode if stderr is not oriented yet.
>> I suggest that POSIX is in error.  ...
> INCITS/ISO/IEC 9899-2011[2012] 7.21 Input/output <stdio.h> 7.21.1 Introduction
> #5 is exactly the same.
>
> However 7.21.3 Files #13 states:
> "In some cases, some of the byte input/output functions also perform conversions
> between multibyte characters and wide characters. These conversions also occur
> as if by calls to the mbrtowc and wcrtomb functions."
>
> This seems to allow for input/output functions not listed in 7.21.1#5 to adapt
> to the stream orientation by using the stream's character input/output
> conversion functions, which could be as above, or a nop.
I had missed that (being under 7.21.3 Files heading rather than 7.21.2 
Streams).  But how are you to know which ones "some" is? There does not seem to 
be a direct list of ones that should be able to do this.  However, the fprintf() 
description of the s format specifier says "If an l length modifier is present, 
the argument shall be a pointer to the initial element of an array of wchar_t 
type. Wide characters from the array are converted to multibyte characters (each 
as if by a call to the wcrtomb function, with the conversion state described by 
an mbstate_t object initialized to zero before the first wide character is 
converted) up to and including a terminating null wide character. The resulting 
multibyte characters are written up to (but not including) the terminating null 
character (byte)."  So fprintf() directly calls for the stated 7.21.1#5 
ability.  Similarly, fscanf() also calls for reverse ability for %ls.  On the 
other hand, perror() does not.  So a reasonable inference is that 7.21.1#5 only 
applies to fprintf() and fscanf() and their derivatives because they directly 
call for the ability, directly mentioning wide to multbyte (and vice versa), 
while the other functions in stdio.h do not (at least, not that I found when 
searching for "multibyte").  While it is an inference that it should not apply 
to others, the inference is supported by the statement that it is "SOME of the 
byte input/output functions": if it is not limited to the ones which 
specifically call for it, then the logical conclusion would be that it should be 
all of them. (It sure would be better if the standard were more specific.)
      (Note:  both fprintf() and fscanf() call for their formats to be 
multibyte.  (E.g. (.21.6.1#3 says "The format shall be a multibyte character 
sequence, beginning and ending in its initial shift state. The format is 
composed of zero or more directives: ordinary multibyte characters (not %), 
which are copied unchanged to the output stream; ...".)  But this spec on the 
formats is not the 7.21.1#5 ability, as it is multibyte passed through to 
byte--it is not conversion of wide to multibyte or vice versa.)
>
>> Please note that perror() is not listed.  ...
>>
>> (Granted, I should probably submit these arguments to POSIX for evaluation, but
>> I don't know how.  Perhaps Eric Blake might be able to help with this,
>> potentially with an off-list discussion.)
> Joseph Myers has some experience submitting C DRs to JTC1/SC22/WG14, who should
> be responsible for any clarification required. Discussions are better on-list.
>
(I didn't mean to discuss the topic off list, I meant possibly discussing the 
mechanics of how this might be done.  That is off the direct topic, but point 
taken, even that might be appropriate for the list.)
By the way, Eric Blake did forward my initial email to the Austin Group to ask 
for an opinion on my opinion (thank you).  I'm sure he'll keep the newlib list 
informed of what that produces.
Craig