Expressions in initializers
Stan Brown
browns at iccgcc.decnet.ab.com
Wed Mar 6 07:42:49 AEST 1991
In article <1032 at caslon.cs.arizona.edu>, dave at cs.arizona.edu (Dave P. Schaumann) writes:
> First thing you need to realize is that there is no special, pre-defined
> function sqrt() in C. (Suprise!!!) The function sqrt lives in a link
> libarary. As far as the C compiler knows, it's just another user-defined
> function. So it can't really be evaluated at compile time.
This was my thought at first, and it's certainly true for non-ANSI compilers.
But App. F.2 of the ANSI standard says undefined behavior results "if the
program redefines a reserved external identifier (4.1.2)."
Sec 4.1.2.1 says: "... All identifiers with external linkage in any of
the following sections (including the future library directions) are
always reserved for use as identifiers with external linkage. ... If a
program declares or defines an identifier with the same name as an
identifier reserved in that context (other than as allowed by 4.1.6),
the behavior is undefined."
Sec 4.1.6 is a page and a half long, but all the referenced 'exceptions'
have to do with declaring library functions, not with custom function
definitions created by the user.
Sec 4.5 is about <math.h>. Sec 4.5.5.2 describes the sqrt function.
So 'sqrt' is a reserved identifier with external linkage, and behavior
is undefined if the user redefined the 'sqrt' identifier by providing
her own sqqrt function.
So a conforming compiler is free to consider sqrt(2.0) to be a
compile-time constant.
Having said all that, I think the way the undefined behavior _should_
work is the way Dave suggests. And I'd expect it to work that way on
any real-life implementation, even though the Standard says we can't
rely on it.
My opinions are mine: I don't speak for any other person or company.
email (until 91/4/30): browns at iccgcc.decnet.ab.com
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA +1 216 371 0043
More information about the Comp.lang.c
mailing list