[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bison-1.875: build feedback
From: |
Nelson H. F. Beebe |
Subject: |
Re: bison-1.875: build feedback |
Date: |
Fri, 3 Jan 2003 16:24:12 -0700 (MST) |
>> ...
>> > 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 -
-------------------------------------------------------------------------------