Austin Group Defect Tracker

Aardvark Mark IV

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 2024-06-11 09:08
Reporter dalias View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Rich Felker
Organization musl libc
User Reference
Section stdin
Page Number 2017
Line Number 64733
Interp Status ---
Final Accepted Text Note: 0005161
Summary 0001347: stderr access mode - "is expected to be" is not defined
Description 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.
Desired Action 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 tc3-2008
Attached Files

- Relationships

-  Notes
geoffclare (manager)
2020-05-29 10:53
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: [^]

and says:
 How is stderr opened: input only (not likely), output only (of course)
 or both (there's the rub)?

 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 (reporter)
2020-05-29 20:26

FYI this issue was opened as a result of discussion on a question posted on Stack Overflow, [^] 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 (manager)
2020-12-10 16:53
edited on: 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.
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.
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 => 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
2024-06-11 09:08 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker