Anonymous | Login | 2024-05-03 01:13 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0000608 | [1003.1(2008)/Issue 7] System Interfaces | Objection | Error | 2012-09-20 11:28 | 2019-06-10 08:55 | ||
Reporter | geoffclare | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Accepted | ||||
Status | Closed | ||||||
Name | Geoff Clare | ||||||
Organization | The Open Group | ||||||
User Reference | |||||||
Section | 2.5 | ||||||
Page Number | 490 | ||||||
Line Number | 16788 | ||||||
Interp Status | --- | ||||||
Final Accepted Text | |||||||
Summary | 0000608: All input/output as if by fgetc()/fputc() is wrong for wide streams | ||||||
Description |
XSH section 2.5 says: "All input takes place as if bytes were read by successive calls to fgetc(); all output takes place as if bytes were written by successive calls to fputc()." This is incorrect for wide-oriented streams, since 2.5.2 says that byte input/output functions cannot be applied to a wide-oriented stream. The equivalent text in C99 is (7.9.13 items 11 and 12): "The wide character input functions read multibyte characters from the stream and convert them to wide characters as if they were read by successive calls to the fgetwc function. Each conversion occurs as if by a call to the mbrtowc function, with the conversion state described by the stream's own mbstate_t object. The byte input functions read characters from the stream as if by successive calls to the fgetc function." "The wide character output functions convert wide characters to multibyte characters and write them to the stream as if they were written by successive calls to the fputwc function. Each conversion occurs as if by a call to the wcrtomb function, with the conversion state described by the stream's own mbstate_t object. The byte output functions write characters to the stream as if by successive calls to the fputc function." We can use this text almost as-is (needs "shallification" and changing "multibyte character" to "character"), although it would also benefit from the addition of forward references to 2.5.2. This covers the byte input/output functions and the wide character input/output functions, but there is also a problem with other functions. For perror(), psiginfo() and psignal() there is a conflict because "as if by fputc()" implies that the functions are required to set an unoriented stream to byte orientation, but the descriptions of the functions say that they do not change the orientation. For the remaining functions getopt() and wordexp() there is the question of whether the requirement to set an unoriented stream to byte orientation matches existing practice. I have tested getopt() on Solaris, HP-UX and Linux; on Linux it does set stderr to byte-oriented when it writes an error message, but on the others it leaves stderr unoriented. I did not test wordexp() since it is already well known that error messages from wordexp() are often written by a child process and therefore would not affect the orientation of stderr in the calling process when that is the case. A related issue is that if getopt() uses a byte output function internally, and since these functions cannot be used on wide oriented streams, applications need to ensure that getopt() will never try to write a message to stderr if it has wide orientation. Similarly for wordexp(). |
||||||
Desired Action |
Replace the sentence: All input takes place as if bytes were read by successive calls to fgetc(); all output takes place as if bytes were written by successive calls to fputc(). with the following four paragraphs: The wide character input functions shall read characters from the stream and convert them to wide characters as if they were read by successive calls to the fgetwc() function. Each conversion shall occur as if by a call to the mbrtowc() function, with the conversion state described by the stream's own mbstate_t object (see [xref to 2.5.2]). The byte input functions shall read characters from the stream as if by successive calls to the fgetc() function. The wide character output functions shall convert wide characters to characters and write them to the stream as if they were written by successive calls to the fputwc() function. Each conversion shall occur as if by a call to the wcrtomb() function, with the conversion state described by the stream's own mbstate_t object (see [xref to 2.5.2]). The byte output functions shall write characters to the stream as if by successive calls to the fputc() function. The perror(), psiginfo() and psignal() functions shall behave as described above for the byte output functions if the stream is already byte-oriented, and shall behave as described above for the wide character output functions if the stream is already wide-oriented. If the stream has no orientation, they shall behave as described for the byte output functions except that they shall not change the orientation of the stream. Functions other than perror(), psiginfo() and psignal() that write to streams but are neither wide character output nor byte output functions (getopt() and wordexp()), shall behave as described above for the byte output functions, except that if the stream has no orientation, it is unspecified whether they set the stream to byte orientation or leave it with no orientation. At page 1040 line 34848 section getopt() change: getopt() shall also print a diagnostic message to stderr in the format specified for the getopts utility. to: getopt() shall also print a diagnostic message to stderr in the format specified for the getopts utility, unless the stderr stream has wide orientation in which case the behavior is undefined. After page 1043 line 34980 section getopt() add a new paragraph to APPLICATION USAGE: Applications which use wide character output functions with stderr should ensure that any calls to getopt() do not write to stderr, either by setting opterr to 0 or by ensuring the first character of optstring is always a <colon>. At page 2258 line 71006 section wordexp() change: wordexp() may write messages to stderr if syntax errors are detected while expanding words. to: wordexp() may write messages to stderr if syntax errors are detected while expanding words, unless the stderr stream has wide orientation in which case the behavior is undefined. After page 2259 line 71038 section wordexp() add a new paragraph to APPLICATION USAGE: Applications which use wide character output functions with stderr should ensure that any calls to wordexp() do not write to stderr, by avoiding use of the WRDE_SHOWERR flag. |
||||||
Tags | tc2-2008 | ||||||
Attached Files | |||||||
|
Notes | |
(0001370) geoffclare (manager) 2012-09-20 13:31 |
Another thought on wordexp()... If the error message is written by a child process, presumably it would always be written to fd 2, which in rare circumstances might not be the same as fileno(stderr). Or do wordexp() implementations check for this and when necessary add "2>&d" (where d is the value of fileno(stderr)) to the shell command they execute? |
(0001382) eblake (manager) 2012-09-26 16:18 |
0000555 addresses the concerns about wordexp() using fd 2 - applications are already required to take care that fileno(stderr) is always 2 if they want conforming behavior. |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |