Subject: Re: pipe(2) and invalid fildes
To: Darren Reed <darrenr@reed.wattle.id.au>
From: James Graham <greywolf@starwolf.com>
List: tech-userlevel
Date: 10/01/2001 08:24:27
On Tue, 2 Oct 2001, Darren Reed wrote:

# There's a lot of "fence sitting" going on in this thread and whilst it
# may be convenient, it should stop.
#
# I have not seen one good argument for leaving EFAULT in the man page.
# A lot of bluster about how it makes it easier to be lazy now and later,
# yes, but nothing else.
#
# >From the 1.5 man page for pipe(2):
# ...
#      [EFAULT]      The fildes buffer is in an invalid area of the process's
#                    address space.
# ...
#
# That does not document, correctly, the current behaviour.  Since it is felt
# that the current behaviour is desired (ie. segmentation fault) then the
# message about EFAULT should simply be removed and no mention of SIGSEGV
# or similar made.

Okay, I misunderstood this whole thing -- it's obviously a man page
accuracy issue.

My wonder was in the opposite direction, i.e. why are we segfaulting on it
instead of returning EFAULT and letting userland deal with it?

# If at some point in the future our implementation of pipe(2) changes, then
# at that time so should the documentation about pipe(2) change.  It is not
# appropriate for man pages for system calls to attempt to be prophetic about
# implementation or speculative about current behaviour.  man pages are
# expected to be concise and accurate.  If anyone can demonstrate how the
# mention of EFAULT adds to the accuracy of the man page, when comapred with
# a version with it absent, I'd like to see it.
#
# Darren
#
# In some email I received from James Graham, sie wrote:
# > On Mon, 1 Oct 2001, der Mouse wrote:
# >
# > # If the manpage is the correct interface definition for pipe(2), then
# > # our implementation is imply *broken*, because if you pass an invalid
# > # pointer, you *don't* get EFAULT back - you get a VM signal in libc.
# >
# > Aren't you supposed to get EFAULT back instead of a core signal on
# > system calls?  I thought it was that way since it was the shortest path
# > to the return.
# >
# > # However, it also seems to me that EFAULT is a kludge: such errors
# > # really *ought* to produce SIGBUS/SIGSEGV, and that they don't is a
# > # historical artifact.  I would favor leaving it basically as it is,
# > # except with a little text added:
# > #
# > #      [EFAULT]      The fildes buffer is in an invalid area of the process's
# > #                    address space.  (An appropriate signal, SIGBUS or
# > #                    SIGSEGV, may be generated instead of returning in this
# > #                    case.)
# > #
# > # Indeed, as I think someone already suggested, I would say that _all_
# > # EFAULT returns, with the possible exception of any that are actually
# > # overloading EFAULT to indicate some other error, should have similar
# > # language added, probably with a note in intro(2) as well.
# >
# > ....what else would you use EFAULT for?
# >
# > ....and if EFAULT is not used to indicate something that would, in
# > userland, generate a SIGBUS or SIGSEGV, do we need to keep the errno?
#


				--*greywolf;
--
Microsoft:	"Where do you want to go today?"
Linux:		"Where do you want to be tomorrow?"
NetBSD:		"Are you guys coming, or what?"