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

Internet Message Format | 1992-08-29 | 3.5 KB

Path: sparky!uunet!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!burley
From: [e-mail] (Craig Burley)
Newsgroups: comp.lang.fortran
Subject: Re: Small Language Wanted
Message-ID: <[e-mail]>
Date: 29 Aug 92 18:35:38 GMT
References: <[e-mail]>
    <H.3lvmyc56w&[e-mail]>
    <[e-mail]>
    <[e-mail]>
    <[e-mail]>
    <[e-mail]
Sender: [e-mail]
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
Lines: 51
In-reply-to: [e-mail]'s message of 28 Aug 92 18:13:27 GMT

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>.

   This policy of C will probably come back to haunt them: suppose the next
   standard wants to add new functions to the standard library?  Reserving
   the names will result in breaking any user codes which happen to have
   functions with those new names.

Interestingly, the standard reserves _sets_ of names for various libraries.
(See Section 14.3 of the Dec 7, 1988 draft; I doubt this has changed in the
official standard.)

So, if you #include <math.h>, not only are the existing names like pow
reserved, but so are all of them suffixed with "f" or "l" (which the lexical
guide gives incorrect examples of, IMHO, since it gives examples like "lpow",
while I think the wording means "powl").

And, if you #include <ctype.h>, not only are names like isspace reserved, but
so are all names beginning with "is" or "to" etc.  (I'd give the grep patterns
of reserved names as "(is\|to)[a-z][a-zA-Z0-9_]*", but I might be getting
the first part wrong, as I don't recall the exact form of an "or" in grep.)

So, C programs _can_ avoid most problems with future versions or enhancements
of C by avoiding the larger sets of reserved names (and, fortunately, it's
quite easy to build tools that check your programs for you; actually, this
seems likely to be easy using existing UNIX tools).

However, I think Fortran programmers have it a bit easier in that they can
avoid the equivalent problem in Fortran just by saying "EXTERNAL FOO" anyplace
they want to refer to FOO as something other than an intrinsic.  It's hard
to really jump up and down over either approach -- the separated "intrinsic"
reserved namespaces of ANSI C or the monolithic namespace with individual
exceptions of Fortran -- but neither of them seems fatal to small or large
applications.
--

James Craig Burley, Software Craftsperson    [e-mail]
Member of the League for Programming Freedom (LPF)