Re: bison-1.875: can abort() et al be user defined?

[Paul Eggert]

> Date: Fri, 3 Jan 2003 19:36:06 -0700 (MST)
> From: "Nelson H. F. Beebe" <address@hidden>
> 
> Paul and the X3J11 Committee are in agreement here, but the Rationale
> is not binding, and it seems to me (and probably other `language
> lawyers') that the language of 4.1.2.1 (1989) and 7.1.3 (1999) says
> only that if foo() is a library function, then foo() must remain a
> function that can be linked externally.

I see how you're reading the text, but I think it's a misreading.
The quote is taken from a section entitled "Reserved identifiers".
The section's context makes it clear that some identifiers are always
reserved; e.g. "__FOO" cannot be defined by any strictly conforming C
program.  Other identifiers are reserved only in certain contexts.
"abort" is one of those: it cannot be defined as an identifier with
external linkage, but it can be defined as an identifier in other
contexts (e.g., as a automatic variable).

I don't think your reading is a plausible one given the quote's
context, but if you still disagree I guess you can submit a request
for interpretation to the committee if you would like any ambiguity to
be cleared up.  The Rationale is a pretty good signal as to how they
would rule, though.

> In practice, most C compiler writers today seem to agree with me:
> the generated code for library routines normally calls them exactly
> like any other user code, and thus, library versions can be
> overridden....

No, though the differences can be subtle.  For example, for this program:

   void abort (void) {}

   int main (int argc, char **argv)
   {
     if (argc == 1)
       abort ();
     else
       return 1;
     return 0;
   }

gcc 3.2 (sparc) issues a warning that abort returns, and then
generates a program that always exits with status 1, regardless of the
value of argc.  This is because GCC assumes that "abort" cannot
return, so it optimizes away the "return 0;" and generates code that
always returns 1.  If you change the two instances of "abort" to
"my_abort", though, GCC issues no warning and the generated program
exits with status 0 if argc is 1.

> The evidence of disagreement among C compiler writers about the meaning
> of this language niche is clear.

C compiler writers are allowed to disagree about the meaning of
programs like the above, since such programs have undefined behavior.