Subject: Re: pipe(2) and invalid fildes
To: None <email@example.com, firstname.lastname@example.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 10/02/2001 00:11:19
>>>> 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
- 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 email@example.com
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B