Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utcs!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!decvax!bellcore!petrus!purtill From: purtill@petrus.UUCP Newsgroups: net.lang.c Subject: Re: Compiler Specific Operators Message-ID: <224@petrus.UUCP> Date: Wed, 16-Jul-86 11:44:02 EDT Article-I.D.: petrus.224 Posted: Wed Jul 16 11:44:02 1986 Date-Received: Wed, 16-Jul-86 22:59:10 EDT References: <1825@uw-beaver> <503@cubsvax.UUCP> <505@cubsvax.UUCP> Organization: Bell Communications Research, Inc Lines: 20 In article <505@cubsvax.UUCP> cubsvax!peters (Peter S. Shenkin) writes: > In article chris@maryland.UUCP (Chris Torek) writes: > >Apparently the committee (or a large faction thereof) is quite > >concerned about ensuring that there is some easy way to ensure a > >`real function call'. > Yes, apparently so, but WHY? What the hell difference does it make, from > the user's point of view? That is, why should he ever be anything other > than happy, if some alternative invoked by the compiler produces faster- > running code? > > Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 > {philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA 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. mark purtill (201) 829-5127 ^.-.^ Arpa: purtill@bellcore.com 435 south st 2H-307 ((")) Uucp: ihnp4!bellcore!purtill morristown nj 07960