IEEE Standards AssociationCopyright © 2006 IEEE. All rights reserved.
Interpretation Number: 029
Topic: popen errors
Relevant Sections: XSH popen------------------------------------------------------------------------
7 Defect Report concerning (number and title of International Standard or DIS final text, if applicable):
The System Interfaces volume of IEEE Std 1003.1-2001
------------------------------------------------------------------------
8 Qualifier (e.g. error, omission, clarification required):
3. Clarification required
------------------------------------------------------------------------
9 References in document (e.g. page, clause, figure, and/or table numbers):
Edition of Specification (Year): 2004 Page: 874 Line: 28523 Section: popen
Reference xshbug2.txt ERN 45
------------------------------------------------------------------------
10 Nature of defect (complete, concise explanation of the perceived problem):
If the mode value is any character other than "r" or "w", according to line 28523 the result is undefined. However, at line 28535, there is a defined error value (under a "may fail").
... assuming that a bad char * pointer will cause undefined behavior, while a good pointer to a bad value will result in EINVAL. This could be explained more clearly. (NOTE, this is not an issue with fdopen or fopen, since these functions do not contain the "undefined" language).
------------------------------------------------------------------------
11 Solution proposed by the submitter (optional):
EITHER Change line 28523 to:
If the value of the mode argument is a valid pointer, but does not reference the strings "r" or "w", popen shall fail and return a null pointer; otherwise the result is undefined.
OR (following fdopen and fopen model): Delete line 28523 [[ leaving simply the "May Fail" error condition]]
------------------------------------------------------------------------
Interpretation response ------------------------
The standards states the error handling requirements for popen(), and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.
Rationale: --------- None.
Notes to the Editor (not part of this interpretation): -----------------------------------------------------
A proposed future revision should change from:
3. If mode is any other value, the result is undefined.
to: 3. If mode is any other value, the result is unspecified.
Back to IEEE Standards Interpretations for IEEE Std 1003.1-2001