Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utcs!mnetor!seismo!cmcl2!rna!cubsvax!peters From: peters@cubsvax.UUCP Newsgroups: net.lang.c Subject: Re: Compiler Specific Operators Message-ID: <509@cubsvax.UUCP> Date: Thu, 17-Jul-86 10:02:04 EDT Article-I.D.: cubsvax.509 Posted: Thu Jul 17 10:02:04 1986 Date-Received: Fri, 18-Jul-86 05:47:32 EDT References: <1825@uw-beaver> <503@cubsvax.UUCP> <505@cubsvax.UUCP> Reply-To: peters@cubsvax.UUCP (Peter S. Shenkin) Organization: Columbia Univ. Bio. CG Fac., NY Lines: 26 In article purtill@petrus.UUCP (Mark Purtill) writes: [re: reasons for not permitting a compiler to expand "function calls" in-line] >Ever heard of debugging? You might well want to set a trap at that >function, or even replace it with a different version that is somehow >useful, such as a version that prints out its arguments. If you want to set a trap, in-line expansion is no worse than having to deal with anything else in your code that doesn't call a function. If you want to replace the built-in function with a new version, either use a new name in-line, or else write a #define to a new name. Since most people don't have source code to the math library anyway, both of your suggestions would seem to be more useful for debugging the compiler or math library than for debugging user code that invokes them. Assuming one has a compiler that works, these features would seem to be of little use to the USER, as opposed to the compiler-writer. And I don't care about the compiler- writer! But I'd still like to hear someone on the committee confirm that this is disallowed (if, in fact, it is!), and comment on what went into the committee's decision to disallow it. Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 {philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA