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 2020-05-29 20:26
Reporter dalias View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Rich Felker
Organization musl libc
User Reference
Section stdin
Page Number 2017
Line Number 64733
Interp Status ---
Final Accepted Text
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 No tags attached.
Attached Files

- Relationships

-  Notes
(0004880)
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:

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

(0004881)
dalias (reporter)
2020-05-29 20:26

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.

- 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


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