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 19:32:10
[ On Sunday, June 13, 1999 at 18:16:32 (-0400), Bill Sommerfeld wrote: ]
> Subject: Re: signal(SIGSEGV, SIG_IGN) -> 100% CPU
> I respectfully disagree. The manual pages *should* document the union
> of the following sets of error codes:
> - codes which can be returned by the current implementation.
> - codes which were returned by our implementation in the past.
> - codes which the implementors want to be able to return in the future.
> - codes which standards we care about say can be returned.
> We want to encourage users of NetBSD to write portable code. We
> document the standards status of our calls; documenting error returns
> and failure modes of system calls helps them to do this.
No thank you! PULEEAZE!!!!!
What the heck is the purpose of a *REFERENCE* manual supposed to be
anyway? I want *exact* documentation about a given implementation.
Anything more or less is most definitely not OK. If I want to look at
other implementations manual pages I can do that. If I want to look at
a "standard" then I can do that. I don't need a half-baked non-standard
manual page that doesn't describe the implementation hosting it!
Certainly historical information is OK, but only so long as it is
explicitly documented as historical and no longer supported.
Information about future migration paths is also OK, but again only so
long as it is explicitly noted as such.
Information about standards conformance, or lack thereof, is equally
welcome, but only if it does not obscure the description of the actual
I do not need another overly genericised "how to program on Unix" book!
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>