NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/fortran/3278

Text File | 1992-08-30 | 2.9 KB | 59 lines

Xref: sparky comp.lang.fortran:3278 comp.std.c:2537
Path: sparky!uunet!mcsun!Germany.EU.net!math.fu-berlin.de!Sirius.dfn.de!darwin.sura.net!wupost!cs.utexas.edu!swrinde!network.ucsd.edu!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
From: [e-mail] (Fergus James HENDERSON)
Newsgroups: comp.lang.fortran,comp.std.c
Subject: Re: Small Language Wanted
Message-ID: <[e-mail]>
Date: 30 Aug 92 07:32:38 GMT
References: <[e-mail]>     <H.3lvmyc56w&[e-mail]>     <[e-mail]>     <[e-mail]>     <[e-mail]>     <[e-mail] <[e-mail]>
Sender: [e-mail]
Organization: Computer Science, University of Melbourne, Australia
Lines: 46

[e-mail] (Craig Burley) writes:

>In article <[e-mail]> [e-mail] (Jim Giles) writes:
>
>   I apologise for posting this incorrect statement.  In fact, all library
>   function names in ANSI standard C are reserved - the user can't define
>   his own.  So the above comment only applies to old K&R implementations
>   which allow the user to do so.  (It's what I get for remembering an old
>   public review copy of the C standard better than the final version.)
>
>Hmm, I don't remember this being true.  I thought pow, for example, was
>a reserved word only if one #include'd <math.h>, and so on.  It's hard to
>be sure without trying to grok the standard right now, but the (occasionally
>inaccurate) "ANSI C: A Lexical Guide" seems to suggest that pow is not a
>reserved word in the way if or for is, unless #include <math.h> is present.
>And, okay I pulled out the standard, and it seems to agree with this; pow
>is reserved only if you #include <math.h>.

If you don't #include <math.h>, then "pow" is not a "reserved word";
but I think that it *is* reserved as an external identifier.
Thus something like
    static double pow(double x,double y) { ... }
should be fine, but to omit the "static" as in
    double pow(double x,double y) { ... }
could cause problems.
[Maybe someone with copy of the standard in front of them can confirm this.]

Note that it makes sense to prevent users from redefining standard library
functions, because doing so could have all sorts of undesireable side-effects.
For example, suppose you redefine pow as
    extern double exp(double), log(double);
    double pow(double x, double y) {
        return exp(y * log(x));
    }
So far, so good. But what if exp happened to be implemented in the
standard library as
    double exp(double x) {
        return pow(2.7182818284, x);
    }
? Now pow() will call exp() which will call pow() which will call exp()...

--
Fergus Henderson             [e-mail]
This .signature virus is a self-referential statement that is true - but
you will only be able to consistently believe it if you copy it to your own
.signature file!