Re: bison-1.875: build feedback

[Nelson H. F. Beebe]

>> ...
>> > Date: Fri, 3 Jan 2003 13:20:23 -0700 (MST)
>> > From: "Nelson H. F. Beebe" <address@hidden>
>> >
>> > Because library functions, including abort() and exit(), can be
>> > redefined by users in the C and C++ programming languages,
>>
>> I don't know about C++, but that is not true for Standard C.  Standard
>> C users are not allowed to redefine 'abort' or 'exit'.  All
>> identifiers with external linkage in the Standard C library are
>> reserved for use as identifiers with external linkage.
>> ...

Can you please cite the section of either ISO C89 or C99 that forbids
redefinition of these identifiers.  I cannot find anything that
suggests that (I have C89 in print, and C99 in electronic form).  In
C99, I find

     7.1.3 Reserved identifiers

     -- All identifiers with external linkage in any of the following
        subclauses (including the future library directions) are
        always reserved for use as identifiers with external
        linkage.154)

      ...

     No other identifiers are reserved.  If the program declares or
     defines an identifier in a context in which it is reserved (other
     than as allowed by 7.1.4), or defines a reserved identifier as a
     macro name, the behavior is undefined.

That only talks about names remaining as external names.  There is
similar wording in C89 (ANSI edition, 4.1.2.1).

This simple test file

        % cat redef.c
        extern void _exit(int);

        void
        abort(void)
        {
        }

        void
        exit(int status)
        {
            _exit(status);
        }

raised no errors on any of several C and C++ compilers that I tried.
"g++ -pedantic" says

        redef.c: In function `void abort()':
        redef.c:6: warning: `noreturn' function does return

but that is still only a warning, indicating a violation of a
convention, not a law.  lcc, and SGI's c89 and CC, which are all very
strict about the Standards, are quite happy with that code.

My comment about wrapper functions was merely to show one way to
reduce the number of warning messages issued by compilers.  I
completely agree that there isn't a universal solution to the problem,
since C and C++ lack a declaration for a function that never returns.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- Center for Scientific Computing       FAX: +1 801 581 4148                  -
- University of Utah                    Internet e-mail: address@hidden  -
- Department of Mathematics, 110 LCB        address@hidden  address@hidden -
- 155 S 1400 E RM 233                       address@hidden                    -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe  -
-------------------------------------------------------------------------------