Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000467 [1003.1(2008)/Issue 7] System Interfaces Objection Enhancement Request 2011-06-29 18:27 2019-06-10 08:55
Reporter eblake View Status public  
Assigned To ajosey
Priority normal Resolution Accepted  
Status Closed  
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
Attached Files

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

-  Notes
(0000867)
eblake (manager)
2011-06-29 21:11

 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).
(0000868)
Don Cragun (manager)
2011-06-29 22:01

 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.
(0000869)
eblake (manager)
2011-06-29 22:46
edited on: 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.
(0000876)
Don Cragun (manager)
2011-06-30 17:04

 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

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker