Answering questions that may arise related to the meaning of portions of an IEEE standard concerning specific applications.

IEEE Standards Interpretations for IEEE Std 1003.1™-2001 IEEE Standard for Information Technology - Portable Operating System Interface (POSIX®)

Copyright © 2006 by the Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue New York, New York 10016-5997 USA All Rights Reserved.

Interpretations are issued to explain and clarify the intent of a standard and do not constitute an alteration to the original standard. In addition, interpretations are not intended to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or portions of this document must contact the IEEE Standards Department for the appropriate license. Use of the information contained in this document is at your own risk.

IEEE Standards Department Copyrights and Permissions 445 Hoes Lane, Piscataway, New Jersey 08855-1331, USA

Interpretation Request #29
Topic: popen errors Relevant Sections: XSH popen

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

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 for Interpretation

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.