On Fri, 11 Jun 1999, Darren Reed wrote:

# In some email I received from Chris G. Demetriou, sie wrote:
# > I.e. the current behaviour (not even checking the pointer 8-) is a bit
# > odd, but not unreasonable.
# 
# Yes, it is.
# 
# > Further than that, a trivial, API-compatible reimplementation might
# > want to detect the error and return EFAULT, so progams and programmers
# > using it should understand what EFAULT means.

The thing is, folks, pipe(2) is a _system_ call, as illustrated by the (2)
in the reference.  System calls, last I looked, were responsible for
checking the bounds of the arguments given them.  pipe() seems to be the
exception, and I, for one (for what _that's_ worth!), would vote that
pipe() needs to be *fixed* to reflect what appears (to me) to be a de facto
standard for what system calls seem to do.

I don't believe that fixing the man page makes it right for pipe() to be
doing what it's doing.  pipe() should be returning EFAULT.  I realise
that "pipe is a special case of socketpair(2) and is actually implemented
as such in the kernel", but if that's the case, since pipe(2) *is* a system
call, the bounds checking should be happening before any operations on the
passed-in data are to be effected.

The statement that it's tantamount to

main() { char *0xdeadbeef = 1; }

is not true, or shouldn't be, as in a call, you're not dereferencing
the bad address until you actually try to modify or read it, while the
above attempts to modify the address immediately.

But I think I'm preaching to the choir at this point, and my brain is
sufficiently fritzed that I don't think I'll be making much sense from
here on, so I'll quit now while I'm behi^H^H^H^Hahead.

# > That is probably true for many or all of the system calls.

...really?  are there any other broken calls we don't know about yet?
System calls are supposed to do bounds checking.

				--*greywolf;
--
NetBSD: Where do you want to have the power to serve tomorrow today?