Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!ittatc!dcdwest!sdcsvax!sdcc6!celerity!ps
From: ps@celerity.UUCP (Pat Shanahan)
Newsgroups: net.lang
Subject: Re:   [Really: C builtin functions?]
Message-ID: <425@celerity.UUCP>
Date: Wed, 16-Apr-86 11:19:56 EST
Article-I.D.: celerity.425
Posted: Wed Apr 16 11:19:56 1986
Date-Received: Fri, 18-Apr-86 20:11:55 EST
References: <443@3comvax.UUCP> <7900003@ztivax.UUCP>
Reply-To: ps@celerity.UUCP (Pat Shanahan)
Organization: Celerity Computing, San Diego, Ca.
Lines: 30
Keywords: C

In article <149@diablo.ARPA> avg@diablo.UUCP (Allen VanGelder) writes:
>I think there may be a confusion in terminology between built-in and
>in-line.  In FORTRAN, MAX is expanded in-line, so you always get
>FORTRAN's MAX.  But SIN is not, and if you jiggle your libraries
>properly you will get your personal SIN function.  The same is true
>for READ and WRITE in FORTRAN.
>
>I still call SIN, READ, and WRITE built-in in any language where the
>language manual tells how to use them and what they do.


It is particularly important to keep this distinction between built-in and
in-line clear, because the in-line attribute is totally implementation
dependent, while built-in implies that the function has a special status in
the language.

For example, SIN is in fact expanded in-line by the Celerity FORTRAN
compiler. To use your personal SIN function you would have the either use an
EXTERNAL statement in the FORTRAN program (indicating that the identifier
SIN refers to a user function not the built-in) or explitly warn the
compiler through a command-line argument not the do the in-line expansion.

The selection of built-in functions that get expanded in-line is more a
reflection of the instruction set for which code is being generated than of
any inherent property of the function.
-- 
	ps
	(Pat Shanahan)
	uucp : {decvax!ucbvax || ihnp4 || philabs}!sdcsvax!celerity!ps
	arpa : sdcsvax!celerity!ps@nosc