[ On Monday, October 15, 2001 at 10:21:06 (+0700), Robert Elz wrote: ]
> Subject: Re: wrap up of pipe(2) 
>
> The NetBSD (or any other system) man pages should document what any NetBSD
> system will do, that is, mostly (one hopes) the same as the standards docs,
> but with lots of the missing parts (read(2) ...) added, and the "left to
> the implementation to define" parts defined as well, as much as they can be.

ah ha!  ``"left to the implementation to define" parts defined as well''

Yes, that's _exactly_ what I want.  It's in fact exactly what I've been
trying to say!  ;-)  Thanks!

> This is essentially the NetBSD standard - the interface that only changes
> after much debate as to the usefulness of the change, compared to its costs.

... and when those implementation specific parts change, I want the
systems documentation to change to match as well of course.  I do not
want it to fall back on the ambiguous standards-style "implementation
defined" wording.


In this case there's no real rock-solid standard definition of what
errors pipe() must detect and return via errno.  SuSv2 says:

     The pipe() function will fail if:
     [EMFILE]
             More than {OPEN_MAX} minus two file descriptors are already in
             use by this process.
     [ENFILE]
             The number of simultaneously open files in the system would
             exceed a system-imposed limit.

so if as an implementor you were to go by that alone you'd be forced to
use a system call interface that can return two file descriptors without
having to pass into the kernel a pointer to user storage, and to always
implement pipe() itself as a user-land wrapper around the actual system
call.

However I suspect if we were to ask the authors of SuSv2 about their
intent here they would not want to rule out the possibility of
implementing pipe() directly as a system call and thus the need for it
to detect a bad pointer and to return a failure with EFAULT.

Indeed SuSv2 has this to say about EFAULT:

     [EFAULT]                                                                   
             Bad address The system detected an invalid address in attempting   
             to use an argument of a call. The reliable detection of this       
             error cannot be guaranteed, and when not detected may result in    
             the generation of a signal, indicating an address violation,       
             which is sent to the process.                                      

That last sentence is, not unsurprisingly, _identical_ to the one now in
pipe(2):1.14 in NetBSD-current as of 2001/10/02.

Unfortunately that last sentence is exactly of the kind mentioned above:
something "left to the implementation to define".  What I and others are
asking for here is that the NetBSD pipe(2) manual page eliminate that
ambiguity, especially since it's clear from the source code that there
is no such ambiguity in the NetBSD implementation(s).  Although pedantic
to the extreme in the specific case of pipe(), this would be ever more
important if there were some NetBSD supported architectures where the
opposite were true (i.e. where EFAULT would always be returned and
SIGSEGV/SIGBUS/etc. impossible; where not all NetBSD systems of a given
release level behaved identically in reporting the error of an invalid
storage pointer being passed to pipe()).


SuSv2 also says this about its definition of pipe():

    DERIVATION

     Derived from Issue 1 of the SVID.

Which should tell you exactly why it doesn't mention EFAULT.

I don't have a copy of P1003.1 to compare.

-- 
							Greg A. Woods

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