Subject: Re: wrap up of pipe(2)
To: Darren Reed <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 10/02/2001 07:03:07
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:
> [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.