In some email I received from Hubert Feyrer, sie wrote:
> 
> On 9 Jun 1999, Chris G. Demetriou wrote:
> > you have effectively written a complex while(1) ; loop, or, probably
> > closer, a whlie(1) getpid(); loop.
> 
> Can you please explain this a bit more? I don't see it...
> By what I understand, this installs the handler, then pipe(2) causes some
> fault, the fault is ignored, and then the program continues.
> 
> Or is the pipe(2) call restarted after the fault is detected?

There are several issues here which received some debate this afternoon
(AEST) on icb.

There are two `problems' here.

The first is that the PC isn't incremented after the fault is handled by
the trap handler, leading to the instruction which caused the fault
continually being retried and since SEGV is ignored, it is not possible
for the program to continue past this point.  Chris argued that this is
`correct' as the address being faulted over _may_ become valid due to some
other action by the program (I guess if you're ignoring SEGV, this may be
a part of that reason ?).

The second is that pipe(2) causes a segmentation violation rather than
returning EFAULT.  To cut a long story short, POSIX doesn't specify that
pipe(2) should return EFAULT although we document it (in pipe(2)) as being
a possible return.  The behaviour that results in this happening is due to
the somewhat bogus manner in which pipe(2) returns the fd's (although there
is some evidence to suggest we are at least consistant with some other
commercial operating systems).  The documentation of it was put aside as
being a BSD vs SYSV thing (i.e. lets pretend we don't need to do anything).
The problem still remains that according to current source code, pipe(2)
can not and will not ever return EFAULT given the description in its man
page and it would seem reasonable that unless someone wants to take it
upon themselves to make it possible for pipe(2) to return EFAULT, the
man page should have the reference to EFAULT removed.

Darren