[ On Sunday, June 13, 1999 at 23:47:54 (+1000), Robert Elz wrote: ]
> Subject: Re: signal(SIGSEGV, SIG_IGN) -> 100% CPU 
>
> As to whether pipe ought be fixed to pass the array to the kernel or not
> that's pretty much irrelevant - if the cost of doing so is worth any
> benefit it will bring, then change it - but don't use EFAULT as a rationale.

I think the rationale is to do so for consistency's sake -- at least
that's the only reason I can think of.

> Historically all sys calls that returned fd's returned them in registers,
> and pipe was no exception, but that hasn't been true for a long time now.

Well in NetBSD pipe() and a few other systems calls that return multiple
int-wide values do still return their results in CPU registers, which is
really what started this whole thread!  ;-)

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.  The distinction that their
results are file descriptors doesn't seem to be strong enough to
validate this difference -- and it's not even true across the board in
BSD.

> Also, historically, time() was a sys call, and it (its C library wrapper)
> would also seg fault if handed a bad address - pipe wasn't than unusual a
> case.   Now time() still seg faults if it is handed a bad pointer, but
> no-one is objecting, because time() is now time(3) rather than time(2),
> and that distinction is supposed to make a difference?

<tangent> The switch from time(2) to time(3) always seemed to be a major
hack, and clearly the ?etimeofday(2) syscalls weren't quite as well
thought out and elegant as they should have been, as evidenced by the
deprecation of their second argument. </tangent>

> Lastly, the man page should not be fixed either - it should list all the
> errors that might occur, and EFAULT is one of those.  It happens that it
> won't occur because the implementation doesn't happen to send the bad
> address to the kernel, but that's no reason that an application might not
> want to check for this and handle it (which is quite different than, say,
> EXDEV which can simply never occur on a pipe call, no matter what).

The application should check for a return value indicating failure
before it looks at errno and the manual page should only document the
return values that are possible.  EFAULT *cannot* possibly occur in any
current NetBSD implementation of the pipe(2) call, no matter what, so
far as I can see.

> What might be worth doing is fixing intro(2) such that it says ..
> 
>      14 EFAULT Bad address. The system detected an invalid address in attempt-
>              ing to use an argument of a call.  The system might generate
> 	     a SIGSEGV signal instead of, or in addition to, generating this
> 	     error.
> 
> That would probably make everyone happy.

I would say that's the worst of all the options.

The syscall manual pages should very explicitly mention *only* those
errno values which might actually be returned by the current
implementation.  Either the pipe(2) system call must be re-implemented
to actually pass the pointer in to the kernel and return EFAULT when
necessary, *or* mention of EFAULT must be removed from the manual page.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>