This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]