Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!virtech!cpcahil
From: cpcahil@virtech.UUCP (Conor P. Cahill)
Newsgroups: comp.lang.c
Subject: Re: parsing the format string at compile time...
Message-ID: <1293@virtech.UUCP>
Date: 20 Oct 89 20:26:23 GMT
References: <705@nixbur.UUCP> <6737@hubcap.clemson.edu> <1856@xyzzy.UUCP> <990@cirrusl.UUCP>
Organization: Virtual Technologies Inc
Lines: 31

In article <990@cirrusl.UUCP>, dhesi@sun505.UUCP (Rahul Dhesi) writes:
> Another typical Usenet example of crosstalk.  Person A, thinking of
> traditional C, says something that is true in that context.  Person B
> (posting from a place where nothing happens), assuming C means ANSI C,
> immediately contradicts.
> 
> Rephrasing:
> 
>      If traditional C did allow this, it would not be traditional C.
>      The traditional C compiler knows nothing about any functions,
>      including I/O.

People may have assumed that this is true in "traditional" C compilers, but
I have run accross several pre-ansi C compilers (like 4 years ago) that
performed inline substitution of functions like strcpy under some
specific circumstances.  At the time these compilers were considered very
good (performance & code wise).

BTW - The only reason I found out about it at the time was that they did not 
correctly emulate the strcpy (in that they did not return a pointer to 
string 1) and in debugging the results we found the inline substitution.

There was no flag in the compiler to turn this off, so we ended up making
lots of changes to work around the bug.


-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+