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

IEEE Standards Interpretation for IEEE Std 1003.1™-1990 IEEE Standard for Information Technology--Portable Operating System Interfaces (POSIX®)

Copyright © 2001 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 #76
Topic: read() Relevant Sections:

I would like a clarification on section 6.4.1 in IEEE Std 1003.1-1990, the System Interface Standard, describing the read() function. In the description in section, it is unclear exactly in what state the caller's read buffer is left after the function returns, in two specific situations:

1. If the read() function returns a value less than "nbyte" but greater than or equal to zero, indicating that the end-of-file was reached, must POSIX implementations guarantee that the remaining bytes in the buffer, from just after the last valid byte transferred to "nbyte"-1, be left unmodified by the read() function? Or is the remainder of the buffer left with undefined contents?

2. Similarly, if the read() function returns an error other than EINTR, must POSIX implementations guarantee that the caller's read buffer is left unmodified, or are the contents undefined? (It seems fairly clear from paragraph 7 that at least for EINTR the contents must be considered undefined, since the OS may return -1 anyway after data has been transferred.)

In the (unlikely I would think) case that this issue hasn't already been dealt with and resolved, my suggested correction would be to state explicitly that after a partial read, the contents of the remainder of the buffer is undefined, and after an error, the contents of the entire read buffer is undefined. In systems that implement read() using some IPC mechanism that may have alignment or size granularity restrictions, it is much more difficult (and in some cases impossible) to implement read() by receiving data from the IPC system directly into the caller's buffer without copying it, if the implementation must guarantee that no more bytes in the read buffer are modified than are actually successfully transferred.

Interpretation Response
For both of these issues, the standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.

Rationale for Interpretation
Once the buffer has been passed to the system, the state of the buffer is undefined. Forwarded to Interpretations group: Apr 10 1996 Forwarded for review: Oct 22 1996 Finalized: Nov 24 1996