>>>> The difference between getting EFAULT and getting SIGSEGV/SIGBUS
>>>> is purely an implementation artifact.
>>> Well, EFAULT can't be returned by pipe(2) currently.  So it seems
>>> wrong to document it as possible return value in manpage.
>> you miss the point.
>> we want to reserve the right for pipe(2) to possibly return EFAULT
>> in the future.
> Then in the future the man page for pipe(2) should be changed to
> document that it now returns EFAULT.
> Changing the man page now to exclude mentioning EFAULT does not
> preclude changing the implementation at a later date.

True as far as it goes, and I'd agree with you, except that:

- pipe is still in section 2;

- historically, and for almost all calls even with modern NetBSD,
  passing an invalid pointer to a section 2 call produces EFAULT rather
  than generating a signal;

- historically, and elsewhere, passing a bad pointer to pipe can return
  EFAULT;

- historically, not all possible failure returns are actually
  documented (ISTR seeing this even under NetBSD at some point).

> The only reason to leave it "as is", now, is laziness & apathy.

No.  (Would laziness and apathy have produced the lengthy discussion
we've seen here?  I don't think so.)

In general, I agree with you that the manpage should describe reality,
and I think that either the implementation or the manpage needs to be
changed here.  I disagree that simply removing EFAULT is the correct
thing to do, though; for the reasons I listed above, I think that even
if the actual behavior is not changed (which it may have to be, for
example if there is a standard we think is worth paying enough
attention to that specifies that a bad address must produce EFAULT
rather than a signal), the manpage should mention EFAULT as a possible
return, indicating that the present implementation does (or perhaps
"may") generate a signal instead.

If we simply omit EFAULT, the points listed above will combine to
produce a strong implication that it's an omission of carelessness
rather than of reality.  At the very least I think a note should be
added to a COMPATABILITY section, or some such, mentioning our
potentially-unexpected behavior in this regard; I think our manpages
should not only describe the implementation but also explain points
where we diverge from what might otherwise reasonably be expected, and
I think this is such a case.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B