[Replying to two messages at once here.]

>> I looked at [making pipe() return EFAULT instead of SEGVing], and it
>> looks pretty simple.
> Of course, since pipe() is implemented in-kernel by socketpair(),

Not in the source tree I looked at ($NetBSD: uipc_syscalls.c,v 1.41);
sys_pipe() more or less mimics sys_socketpair(), but the two do not
actually share any common "create a connected pair of sockets" code.

Interestingly, socketpair() *does* return the file descriptors via
copyout(), unlike pipe().

> we could just call the latter from user space directly ....

I once thought that's how pipe() was done now (ie, it was really
pipe(3) rather than pipe(2)).  But syscall traces and code reading
dispelled that illusion quickly. :-)

>> The only benefits I can see to changing this are (1) uniformity with
>> other syscalls, and the (current) manpage, wrt invalid pointer
>> arguments (EFAULT instead of a signal), and (2) removing a
>> special-case syscall from libc.
> My further argument was that the manual page wasn't even incorrect.

I agree with this last-quoted message (from cgd); with the wording
change it suggests ("will fail if" -> "can fail if", more or less), the
manpage becomes a complete non-issue.  Nevertheless, uniformity of
semantics with other syscalls (especially socketpair(), it seems to me)
and uniformity of implementation with almost all other syscalls strike
me as reasons enough to do the change.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B