Date:        Sat, 12 Jun 1999 18:38:54 -0700 (PDT)
    From:        Gandhi woulda smacked you <greywolf@starwolf.com>
    Message-ID:  <Pine.NEB.4.02.9906121828350.3765-100000@defender.starwolf.com>

  | The thing is, folks, pipe(2) is a _system_ call, as illustrated by the (2)
  | in the reference.  System calls, last I looked, were responsible for
  | checking the bounds of the arguments given them.

That's true, but the rationale for this is to protect the kernel, not
to provide the user with a signal free way of determining whether an
address is bad or not.

The only reason EFAULT exists at all is that correctly simulating a SIGSEGV
from inside the kernel when it detects the bad address is simply way too much
work for too little conceivable gain.

If things were to be done properly, applications would get SIGSEGV whenever
they cause a bad address to be referenced, there'd be no exemption for
sys calls.

As to whether pipe ought be fixed to pass the array to the kernel or not
that's pretty much irrelevant - if the cost of doing so is worth any
benefit it will bring, then change it - but don't use EFAULT as a rationale.
Historically all sys calls that returned fd's returned them in registers,
and pipe was no exception, but that hasn't been true for a long time now.
Also, historically, time() was a sys call, and it (its C library wrapper)
would also seg fault if handed a bad address - pipe wasn't than unusual a
case.   Now time() still seg faults if it is handed a bad pointer, but
no-one is objecting, because time() is now time(3) rather than time(2),
and that distinction is supposed to make a difference?

Lastly, the man page should not be fixed either - it should list all the
errors that might occur, and EFAULT is one of those.  It happens that it
won't occur because the implementation doesn't happen to send the bad
address to the kernel, but that's no reason that an application might not
want to check for this and handle it (which is quite different than, say,
EXDEV which can simply never occur on a pipe call, no matter what).

What might be worth doing is fixing intro(2) such that it says ..

     14 EFAULT Bad address. The system detected an invalid address in attempt-
             ing to use an argument of a call.  The system might generate
	     a SIGSEGV signal instead of, or in addition to, generating this
	     error.

That would probably make everyone happy.

kre