In <tech-kern-ownerATnetbsd.org--199906100336.NAA02779@avalon.reed.wattle.id.au>, Darren Reed wrote: 
> 
> When using signal(SIGSEGV, SIG_IGN), should one expect CPU usage to
> sky rocket to ~100% of that process ?  I posted earlier re. pipe(2)
> causing a segmentation fault rather than returning EFAULT, HOWEVER,
> I attempted to bypass this with ignoring SEGV, except that has not
> worked as planned.  If this is a bug somewhere, I'll file a PR.  If
> not, it seems pretty damn stupid.  FWIW, this is being tested on a
> SHARK.  Test program below.

The instruction causing the segmentation violation is being restarted,
hence your endless loop. Posix 1003.1b, secton 3.3.1.3 explicitly says
the behaviour of a process ignoing SIGSEGV is undefined.

To survive a segmentation violation, you need to longjump out of a
SIGSEGV handler.

I also think calling pipe with a pointer to nowhere should coredump,
not return an error code. You're not passing a wrong value. You're
passing a pointer that points to no value at all, not even an invalid
one.

Regarding the bidirectional pipes: POSIX 1003.1b clearly states that
they only need to be unidirectonal, that means one fd is for reading
only, the other for writing only. However, implementations that allow
both descriptors to be used for read and write (such as FreeBSD) do
not violate this specifications.

Personally, I would prefer a different system call (or library
wrapper) for bidirectonal pipes. I had a nice surprise when I wrote a
program on FreeBSD and failed on a system with unidirectional pipes
because I accidentially exchanged the reading and writing end and
didn't notice on FreeBSD.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
"Where do you want to do today?" Hard to tell running your calendar 
 program on a junk operating system, eh?