On Thu, 4 Oct 2001, Darren Reed wrote:

> In some email I received from a luser, sie wrote
> > On Wed, 2001-10-03 at 14:10, Darren Reed wrote:
> > >
> > > Comments on the the following change for pipe(2) ?
> >
> > Bill already took care of this.  `Go away.'
>
> The person who said that should just have not said anything.
> There are a million and one other ways you could have said
> that without being such a rude ass like that.

Yes, well, that could make a rather large thread. :-)

> That said, I do not think that the current incarnation is clear enough.
> It reads:
>
> ...
> ERRORS
> ...
>      [EFAULT]      The fildes buffer is in an invalid area of the process's
>                    address space.  The reliable detection of this error cannot
>                    be guaranteed and when not detected may result in the gen-
>                    eration of a signal, indicating an address violation, which
>                    is sent to the process.
>
> I still feel this is wrong because the emphasis on the detection is wrong.
> I'd go so far as to say that if we cannot reliably detect this type of error
> then that should be classed as a bug :-)

I agree and disagree with you. I agree that this wording is sub-optimal,
but I don't think it's a bug. I also realize I don't have better wording
to add. :-)

I think part of the problem is we're talking about pipe(2), when the error
actually comes from pipe(3). It's a library stub which generates the
error, not the kernel. Since the vast majority of our library routines
deal with address errors by generating signals (bus errors for instance),
I don't see why this routines similar behavior is a problem.

Take care,

Bill