Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl
From: karl@haddock.UUCP
Newsgroups: comp.lang.c
Subject: Re: Types
Message-ID: <710@haddock.ISC.COM>
Date: Fri, 10-Jul-87 14:46:33 EDT
Article-I.D.: haddock.710
Posted: Fri Jul 10 14:46:33 1987
Date-Received: Sun, 12-Jul-87 11:16:26 EDT
References: <7264@brl-adm.ARPA> <734@sdchema.sdchem.UUCP>
Reply-To: karl@haddock.ISC.COM.UUCP (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 26

In article <13220@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes:
>Excuse me, but doesn't the compiler standard make provision for functions
>being built-in?  I seem to remember provision having to be made to make
>sure one could defeat built in compiler treatment of certain math functions
>that were turned into inline code and allowing the user to make them true
>function calls

Yes.  This can be done with "#undef", or by enclosing the name in parens.

>(presumably because the programmer wanted to make his own version of the
>function).

No, such a substitution yields undefined behavior, even if the user function
has identical semantics.

>What makes asm("string") any different than someones version of log(x) that
>might get turned into a call to the machines log instruction, unless it was
>explicitly turned off?

"log" is part of the standard, "asm" is not.  Thus, a strictly conforming
implementation must assume by default that "asm" refers to a user function.
However, the builtin could be named "__asm"; then the user could explicitly
enable it with "#define asm __asm".  Alternately, the feature could be enabled
via "#pragma".

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint