View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000467 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2011-06-29 18:27 | 2019-06-10 08:55 |
Reporter | eblake | Assigned To | ajosey | ||
Priority | normal | Severity | Objection | Type | Enhancement Request |
Status | Closed | Resolution | Accepted | ||
Name | Eric Blake | ||||
Organization | Red Hat | ||||
User Reference | ebb.pipe | ||||
Section | pipe | ||||
Page Number | 1400 | ||||
Line Number | 45851 | ||||
Interp Status | --- | ||||
Final Accepted Text | |||||
Summary | 0000467: pipe should not modify fd on failure | ||||
Description | The standard is currently silent on the contents of filedes[0] and filedes[1] if pipe( ) fails, however, in the implementations that I surveyed, these values were unchanged. Adding a requirement to enforce this behavior can simplify some coding styles. Currently, I have to use: int fd[2] = { -1, -1 }; ... //do some work, which might goto error if (pipe(fd) < 0) { fd[0] = fd[1] = -1; goto error; } //do some more work, which might goto error ... error: if (fd[0] != -1) close(fd[0]); if (fd[1] != -1) close(fd[1]); //more cleanup; But if we guarantee that filedes is unchanged on error, then the implementation can rely on the previous contents, and skip the (re-)assignment of the fd contents to -1 on error, using: if (pipe(fd) < 0) goto error; | ||||
Desired Action | At line 45851 [XSH pipe RETURN VALUE], change: otherwise, −1 shall be returned and errno set to indicate the error. to: otherwise, −1 shall be returned, the contents of filedes left unmodified, and errno set to indicate the error. | ||||
Tags | tc2-2008 |
|
For the record, I tested with this program: #define _POSIX_C_SOURCE 200811L #include <unistd.h> #include <string.h> #include <stdio.h> #include <errno.h> int main (int argc, char **argv) { int i = 0; while (1) { int fd[2] = {-2,-3}; int err = pipe(fd); if (err) { printf ("iteration %d, pipe returned %d errno %d %s, fds %d %d\n", i, err, errno, strerror(errno), fd[0], fd[1]); break; } i++; } return 0; } And on all of AIX, HP-UX, IRIX, Linux, Solaris, Tru64, FreeBSD, OpenBSD, and MacOS, the output ended with "-2 -3", showing that it is common implementation practice to leave filedes untouched on error. The value of errno was generally EMFILE, although in the FreeBSD case it was ENOMEM (this is arguably a bug in FreeBSD). |
|
If a programmer passes a bad address (very close to the end of allocated space) to pipe(), there is a good chance that it would correctly set the fildes[0] and get a SIGBUS or SIGSEGV while filling in fildes[1]. If the signal is caught or ignored, pipe() should return with something like an [EFAULT]. In a case like this I don't think it is reasonable to require the implementation to save and restore the original value of fildes[0] as suggested by this proposed change. |
|
The standard is already clear that passing a bad pointer (such as one very close to the end of allocated space) is in the realm of undefined behavior, and hence, it is perfectly acceptable for such an implementation to set filedes[0] and still fail with errno set to EFAULT. There is a reason that the standard does not mention EFAULT, and that reason is that it is already permitted by the catch-all clause that gives undefined behavior to all bad pointers. This proposal does not force an implementation to save and restore filedes[0] on bad pointers. |
|
With the changes suggested in the Desired Action, the RETURN VALUE section becomes:Upon successful completion, 0 shall be returned; otherwise, −1 shall be returned, the contents of filedes left unmodified, and errno set to indicate the error. I had mistakenly interpreted this to be an explicit statement that should override the undefined behavior specified in XSH section 2.1.1 (Use and Implementation of Functions) point 1. The lead in to this section (P467, L15855-15856) states: Each of the following statements shall apply to all functions unless explicitly stated otherwise in the detailed descriptions that follow: and the first point in that list on the following lines says: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer), the behavior is undefined. During the Austin Group conference call on June 30, 2011, we discussed this point and all agreed that the new wording proposed here does not count as an explicit exception to getting undefined behavior if a bad pointer is given to pipe(). If the standard intended to override the undefined behavior it would need to say something explicitly listing the undefined behavior that is being overridden, such as: Upon successful completion, 0 shall be returned; otherwise, −1 shall be returned, the contents of filedes left unmodified even if filedes points outside the address space of the program, and errno set to indicate the error. |
Date Modified | Username | Field | Change |
---|---|---|---|
2011-06-29 18:27 | eblake | New Issue | |
2011-06-29 18:27 | eblake | Status | New => Under Review |
2011-06-29 18:27 | eblake | Assigned To | => ajosey |
2011-06-29 18:27 | eblake | Name | => Eric Blake |
2011-06-29 18:27 | eblake | Organization | => Red Hat |
2011-06-29 18:27 | eblake | User Reference | => ebb.pipe |
2011-06-29 18:27 | eblake | Section | => pipe |
2011-06-29 18:27 | eblake | Page Number | => 1400 |
2011-06-29 18:27 | eblake | Line Number | => 45851 |
2011-06-29 18:27 | eblake | Interp Status | => --- |
2011-06-29 21:11 | eblake | Note Added: 0000867 | |
2011-06-29 22:01 | Don Cragun | Note Added: 0000868 | |
2011-06-29 22:46 | eblake | Note Added: 0000869 | |
2011-06-29 22:47 | eblake | Note Edited: 0000869 | |
2011-06-29 22:47 | eblake | Note Edited: 0000869 | |
2011-06-30 15:27 | msbrown | Tag Attached: tc2-2008 | |
2011-06-30 15:28 | msbrown | Status | Under Review => Resolved |
2011-06-30 15:28 | msbrown | Resolution | Open => Future Enhancement |
2011-06-30 17:04 | Don Cragun | Note Added: 0000876 | |
2011-06-30 17:06 | Don Cragun | Resolution | Future Enhancement => Accepted |
2011-08-03 22:58 | eblake | Relationship added | related to 0000483 |
2011-11-29 14:16 | eblake | Relationship added | related to 0000520 |
2013-02-07 16:53 | eblake | Relationship added | related to 0000623 |
2019-06-10 08:55 | agadmin | Status | Resolved => Closed |