View Issue Details

IDProjectCategoryView StatusLast Update
00013471003.1(2016/18)/Issue7+TC2System Interfacespublic2024-06-11 09:08
Reporterdalias Assigned To 
PrioritynormalSeverityEditorialTypeClarification Requested
Status ClosedResolutionAccepted As Marked 
NameRich Felker
Organizationmusl libc
User Reference
Sectionstdin
Page Number2017
Line Number64733
Interp Status---
Final Accepted Text0001347:0005161
Summary0001347: stderr access mode - "is expected to be" is not defined
DescriptionThe 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.
Desired ActionClarify 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.
Tagstc3-2008

Activities

geoffclare

2020-05-29 10:53

manager   bugnote:0004880

Last edited: 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:

http://www.opengroup.org/austin/docs/austin_34r1.txt

and says:
 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).

dalias

2020-05-29 20:26

reporter   bugnote:0004881

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.

rhansen

2020-12-10 16:53

manager   bugnote:0005161

Last edited: 2020-12-10 17:02

On page 65 before line 1912 (XBD "interactive shell") insert a new definition and renumber the remaining:
Interactive Device

A terminal device.

Note: This definition is intended to align with the ISO C standard's use of "interactive device".

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().

Issue History

Date Modified Username Field Change
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 => 0001347: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
2024-06-11 09:08 agadmin Status Applied => Closed