Date:        Sun, 13 Jun 1999 13:01:52 -0400 (EDT)
    From:        woods@most.weird.com (Greg A. Woods)
    Message-ID:  <m10tDdo-000gAAC@most.weird.com>

  | It has always seemed to me to be rather inelegant that some of the
  | system calls that apparently take pointers from the C API's point of
  | view don't actually do so under the hood.

What is inelegant is the distinction between what is a sys call, and what
isn't.   If you prefer, think of pipe() as being a libc function which
happens to make a system call to do a part of its work.   Just like
fwrite() for example.   Both are handed a pointer, both will segv if
the pointer is invalid.   Both execute a sys call to do a part of their
work, and do some more of it in the library code.   There's no real
difference between the two.   pipe() could be made a (3) function by
making it a wrapper for socketpair(2) (or, if necessary, something with
the precise semantics -- I don't recall if there might be some slight
differences, related to stuff like atomic writes, with socketpair()).
Or, we could even make fwrite() a sys call (pass in the FILE * and have
the kernel do all of the work, including generating EFAULT on any bad
pointer).   The distinction between (2) and (3) is silly.   It existed
in ancient unix purely because of the radically different calling sequence
for a sys call compared to a libc function when called from asssembler code
(back in the days when a good fraction of unix userland was written in as).

The only thing relevant here is that a program which gets either a
SEGV, or an EFAULT (and isn't an original v7 style /bin/sh) is simply
broken, and ought to be fixed, and which of those it gets shouldn't matter
in the slightest.   (And if you want to argue that 7th edn sh is also
broken, I won't argue - I recall the pains involved in making it work
on a system where seg faults weren't restartable).

The rest of your message (the relevant parts anyway) has been answered
by others.

kre