Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!abvax!iccgcc!browns
From: browns@iccgcc.decnet.ab.com (Stan Brown)
Newsgroups: comp.lang.c
Subject: Re: Expressions in initializers
Message-ID: <3599.27d3ca8a@iccgcc.decnet.ab.com>
Date: 5 Mar 91 21:42:49 GMT
References: <17270@crdgw1.crd.ge.com> <760@ajpo.sei.cmu.edu> <1991Mar4.144939.8311@ux1.cso.uiuc.edu> <1032@caslon.cs.arizona.edu>
Lines: 39

In article <1032@caslon.cs.arizona.edu>, dave@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@iccgcc.decnet.ab.com
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA    +1 216 371 0043