Subject: Re: signal(SIGSEGV, SIG_IGN) -> 100% CPU
To: Chris G. Demetriou <>
From: Darren Reed <>
List: tech-kern
Date: 06/11/1999 10:47:05
In some email I received from Chris G. Demetriou, sie wrote:
> der Mouse  <mouse@Rodents.Montreal.QC.CA> writes:
> > But is it worth it?  The only benefits I can see to changing this are
> > (1) uniformity with other syscalls, and the (current) manpage, wrt
> > invalid pointer arguments (EFAULT instead of a signal), and (2)
> > removing a special-case syscall from libc.
> My further argument was that the manual page wasn't even incorrect.
> The errors section of the manual pages are, as far as I know, meant to
> be read "if you get this error, it is because of this error cause," or
> "if this error cause is detected, you will get this error."

And what if you make no attempt to detect an error ?

> I.e. the current behaviour (not even checking the pointer 8-) is a bit
> odd, but not unreasonable.

Yes, it is.

> Further than that, a trivial, API-compatible reimplementation might
> want to detect the error and return EFAULT, so progams and programmers
> using it should understand what EFAULT means.

But currently doesn't.  If someone were to make that change then they'd
need to make the appropriate documentation changes.

> Re-reading the manual page, i'd say that there is one problem:
>      The pipe() call will fail if:
> should be
>      The following errors may be reported:
> (a la sysctl(3)).
> That is probably true for many or all of the system calls.

The problem is we *know* it can't so IMHO, the man page is still incorrect
as it suggests behaviour that is false.