Subject: Re: signal(SIGSEGV, SIG_IGN) -> 100% CPU
To: Chris G. Demetriou <firstname.lastname@example.org>
From: Darren Reed <email@example.com>
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.