View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00004671003.1(2008)/Issue 7System Interfacespublic2011-06-29 18:272019-06-10 08:55
Reportereblake Assigned Toajosey  
PrioritynormalSeverityObjectionTypeEnhancement Request
Status ClosedResolutionAccepted 
NameEric Blake
OrganizationRed Hat
User Referenceebb.pipe
Sectionpipe
Page Number1400
Line Number45851
Interp Status---
Final Accepted Text
Summary0000467: pipe should not modify fd on failure
DescriptionThe 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 ActionAt 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.
Tagstc2-2008

Relationships

related to 0000483 Closedajosey socketpair should not modify socket_vector on failure 
related to 0000520 Closedajosey posix_memalign should not modify memptr on failure 
related to 0000623 Closedajosey poll should not modify fds[i].fd and fds[i].events 

Activities

eblake

2011-06-29 21:11

manager   bugnote:0000867

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

Don Cragun

2011-06-29 22:01

manager   bugnote:0000868

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.

eblake

2011-06-29 22:46

manager   bugnote:0000869

Last edited: 2011-06-29 22:47

 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.

Don Cragun

2011-06-30 17:04

manager   bugnote:0000876

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.

Issue History

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