Subject: Re: signal(SIGSEGV, SIG_IGN) -> 100% CPU
To: NetBSD Kernel Technical Discussion List <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 06/13/1999 22:16:40
[ On Monday, June 14, 1999 at 09:16:57 (+1000), Giles Lean wrote: ]
> Subject: Re: signal(SIGSEGV, SIG_IGN) -> 100% CPU
> Of course all the values that can be returned must be listed. Adding
> those specified in the relevant standards that can't actually be
> returned by the current implementation is good for portability.
Unfortunately this kind of attitude leads to very sloppy documentation.
I want documentation that describes the system as it is implemented, not
some ideal that doesn't exist in real life.
Documenting error codes that can't happen can also lead programmers to
making very dangerous assumptions (eg. you might assume that an error
condition is handled by the system call and then find out far too late
that the opposite is true on some particular system that gave you only
so-called "helpful" and misleading documentation). This is in effect
exactly what happened to Darren.
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>