Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ulysses.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!jss
From: jss@ulysses.UUCP (Jerry Schwarz)
Newsgroups: net.lang.c
Subject: Re: C Builtin Functions
Message-ID: <1253@ulysses.UUCP>
Date: Thu, 8-May-86 17:42:25 EDT
Article-I.D.: ulysses.1253
Posted: Thu May  8 17:42:25 1986
Date-Received: Fri, 9-May-86 10:54:59 EDT
References: <1700010@umn-cs.UUCP> <788@bentley.UUCP> <479@ncr-sd.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 34

> I'm surprised that with all this discussion on built-ins, nobody has pointed
> out how the C standard specifies that it should work.  My copy of the standard
> is pretty old and has been stolen, so perhaps it was removed in a later
> specification?
> 

It was about the 3rd item posted in the discussion.  But here it is
again (Februray 1986 draft)

        D.1.2 Headers

        ... All external identifiers declared in any of the headers
        [i.e. as specified in the standard] are reserved, whether or
        not the associated header is included. All external
        identifiers and macro names that begin with an underscore are
        also reserved.  If the program redefines a reserved external
        identifier, even with a semantically equivalent form the
        behavior is implementation defined. ...

        D.1.3 Use of library functions

        ... Any function declared in a header may be implemented as a
        macro defined in the header, so a library function should not
        be declared explicitly if its header is included. ... The use
        of #undef to remove any macro definition will also ensure
        that  an actual function is referenced.

To me this seems perfectly reasonable.  Note in particular that a
vendor is required to tell you what will happen if you try to redefine
one of the reserved identifiers.  

Jerry Schwarz 
Bell Labs, MH  
ulysses!jss