|Anonymous | Login||2023-03-29 13:04 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|
|0001347||[1003.1(2016/18)/Issue7+TC2] System Interfaces||Editorial||Clarification Requested||2020-05-28 19:50||2020-12-16 16:00|
|Priority||normal||Resolution||Accepted As Marked|
|Final Accepted Text||Note: 0005161|
|Summary||0001347: stderr access mode - "is expected to be" is not defined|
The specification of the standard FILE streams includes the (CX shaded) text:
"The stderr stream is expected to be open for reading and writing."
As far as I can tell, the wording "is expected to be" is not defined anywhere in the standard, and is unclear as to which party may use the expectation and which is responsible for ensuring that it is satisfied.
In addition, it's unclear whether the intent was that the expectation apply to the underlying open file description behind fd 2, or the stderr stdio FILE stream. The latter does not seem useful since dual-mode streams are only usable on seekable files (there's no way to switch from reading to writing without a successful seek) but the use of the word "stream" in the above-quoted suggests it should be read that way. Moreover, even if the stream is open for reading and writing, that does not automatically imply that the file descriptor is.
Clarify which party (implementation, invoking application, or something else) the obligation is on and which party may have the expectation.
Clarify what the consequences are if the expectation is not satisfied.
Clarify whether the statement applies to the FILE stream, the underlying open file description's mode, or both.
edited on: 2020-05-29 12:16
After a bit of digging (with help from Andrew J) it appears that this wording arose as a result of ERN 40 against XSH6 draft 1, which can be seen here:
Problem: How is stderr opened: input only (not likely), output only (of course) or both (there's the rub)? Action: My preference: "stderr is opened for input and output, although it is expected that under normal circumstances it will not be used for input". I'm OK with "stderr is opened for output. Implementations may open it for input as well, but a conforming application should not expect that."
It was submitted by someone called Donn with an Interix email address, which I assume is Donn Terry. If Donn reads this perhaps he can remember what led him to raise this.
My initial guess was that it is is related to the more utility reading commands from "standard error", but since more doesn't have to be implemented in C (and anyway could use read() rather than stdio) there would have been no need to raise the matter in connection with C's stderr but only for file descriptor 2 (as inherited by the login shell).
|FYI this issue was opened as a result of discussion on a question posted on Stack Overflow, https://stackoverflow.com/questions/62052909 [^] where it was found that at least glibc, FreeBSD, and OpenBSD all have the stderr FILE stream in write-only mode. So it seems that an interpretation applying the text in question as a requirement on the implementation's definition of stderr would be contrary to fairly widespread existing practice.|
edited on: 2020-12-10 17:02
On page 65 before line 1912 (XBD "interactive shell") insert a new definition and renumber the remaining:
On page 496 lines 17224-17228 (XSH 2.5 Standard I/O Streams) and page 2017 lines 64723-64727 (XSH stderr, stdin, stdout DESCRIPTION) change:
At program start-up, three streams shall be predefined and need not be opened explicitly: standard input (for reading conventional input), standard output (for writing conventional output), and standard error (for writing diagnostic output). When opened, the standard error stream is not fully buffered; the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device.to:
At program start-up, three streams shall be predefined and already open: stdin (standard input, for conventional input) for reading, stdout (standard output, for conventional output) for writing, and stderr (standard error, for diagnostic output) for writing. When opened, stderr shall not be fully buffered; stdin and stdout shall be fully buffered if and only if [CX]the file descriptor associated with the stream is determined not to be associated with an interactive device.[/CX]
On page 2017 line 64733 (XSH stdin DESCRIPTION), change:
The stderr stream is expected to be open for reading and writing.to:
These file descriptors are often all associated with a single open file description which has access mode O_RDWR (e.g., in the case of a terminal device for a login shell). However, the stderr, stdin, and stdout streams need not be opened for both reading and writing at program start-up in this case.
On page 2017 line 64747 (stdin SEE ALSO) add isatty().
|2020-05-28 19:50||dalias||New Issue|
|2020-05-28 19:50||dalias||Name||=> Rich Felker|
|2020-05-28 19:50||dalias||Organization||=> musl libc|
|2020-05-28 19:50||dalias||Section||=> stderr|
|2020-05-28 19:50||dalias||Page Number||=> unknown|
|2020-05-28 19:50||dalias||Line Number||=> unknown|
|2020-05-28 23:00||Don Cragun||Section||stderr => stdin|
|2020-05-28 23:00||Don Cragun||Page Number||unknown => 2017|
|2020-05-28 23:00||Don Cragun||Line Number||unknown => 64733|
|2020-05-28 23:00||Don Cragun||Interp Status||=> ---|
|2020-05-29 10:53||geoffclare||Note Added: 0004880|
|2020-05-29 10:59||geoffclare||Note Edited: 0004880|
|2020-05-29 12:16||geoffclare||Note Edited: 0004880|
|2020-05-29 20:26||dalias||Note Added: 0004881|
|2020-12-10 16:53||rhansen||Note Added: 0005161|
|2020-12-10 17:00||rhansen||Final Accepted Text||=> Note: 0005161|
|2020-12-10 17:00||rhansen||Status||New => Resolved|
|2020-12-10 17:00||rhansen||Resolution||Open => Accepted As Marked|
|2020-12-10 17:01||rhansen||Tag Attached: tc3-2008|
|2020-12-10 17:02||rhansen||Note Edited: 0005161|
|2020-12-16 16:00||geoffclare||Status||Resolved => Applied|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|