|Anonymous | Login||2020-07-06 09:49 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001347||[1003.1(2016)/Issue7+TC2] System Interfaces||Editorial||Clarification Requested||2020-05-28 19:50||2020-05-29 20:26|
|Final Accepted Text|
|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.
|Tags||No tags attached.|
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.|
|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|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|