"Perry E. Metzger" <perry@wasabisystems.com> writes:

> "Jarom=81=EDr" Dolecek <jdolecek@netbsd.org> writes:
> > SUSv2 manpage doesn't even note EFAULT in ERRORS, not mention
> > anything in the pipe(2) manpage text. So, it seems NetBSD behaviour
> > is standards-conforming and thus correct. At least to the extend
> > that it's permitted to either crash or return EFAULT, and no from
> > these two is necessarily more correct that other.
> >=20
> > Thoughs? I'd like to update the manpage and remove the EFAULT
> > from errors, and close the PR.
>=20
> This seems highly wrong.
>=20
> SuS states a minimum set of behaviors, not all the behaviors that an
> implementation may have. It is perfectly fine for an implementation to
> catch more errors than SuSv2 specifies, and indeed, removing error
> handling capability seems wrong. In particular, I think that it is
> reasonable for pipe() to detect that it has been passed an invalid
> pointer and do something reasonable instead of crashing.

There's an important issue here that you're glossing over. System
calls must check user addresses for validity anyway, and so they get
EFAULT handling for free. User-level library code does not generally
go out of its way to detect error conditions like invalid addresses;
doing so would introduce a performance penalty for an error condition
that is detected by the VM system just fine.

The pipe(2) system call proper doesn't take a user-level address; it
just returns two file descriptors. User-level wrapper code pastes
those into the provided array.

EFAULT is in the class of errors that an implementation is permitted
to catch if it is convenient. In the case of the pipe(2) library
routine, it is not convenient. Making pipe(2) return EFAULT makes no
more sense than making printf(3) return EFAULT.

The correct fix is to not declare that pipe(2) will return EFAULT. At
most, we could say that it "may" return EFAULT if the error is
invalid, but that a programmer can't rely on that to happen in all
cases.

        - Nathan