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