Subject: Re: signal(SIGSEGV, SIG_IGN) -> 100% CPU
To: None <email@example.com, firstname.lastname@example.org>
From: Ross Harvey <email@example.com>
Date: 06/14/1999 18:22:30
> From firstname.lastname@example.org Mon Jun 14 14:37:47 1999
> To: Todd Vierling <email@example.com>
> cc: firstname.lastname@example.org
> Subject: Re: signal(SIGSEGV, SIG_IGN) -> 100% CPU
> Date: Tue, 15 Jun 1999 07:38:26 +1000
> From: Giles Lean <email@example.com>
> On Mon, 14 Jun 1999 15:21:02 -0400 (EDT) Todd Vierling wrote:
> > Uh, no. See src/lib/libc/include/namespace.h.
> Query -- more userland than kernel, but the thread's here -- why do we
> use weak aliases with a single '_' prefix? I thought ANSI/ISO C in
> the final standard (but not in some drafts) left _[a-z] in the user's
_[A-Z_]... ``always reserved either for any use or for use
as file scope identifiers''
_A reserved for any use
__a reserved for any use
_... ``reserved for use as identifiers with file scope''
_... ``all external identifiers that ... are reserved''
It's compliant, in two or three different ways, depending on how you parse
the amazingly poor wording of section 7.1.3.
Footnotes elsewhere in the C89 doc make it clear that it was their intention
to reserve all _ external identifiers, but only some _ macro names. It's
true that the actual language of section 7.1.3 is so awkward and clumsy
that it appears to be saying the opposite.
1. We are saved by the Posix rule, as the weak alias feature is to purify
the Posix namespace, and no conforming Posix program can use any _
2. As long as those non-standard functions really are optional, then a
conforming program may use the names, and the linker will silently ignore
the objects with the same name in the libraries, so even by the literal
interpretation of 7.1.3 we should be OK.