Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!ginosko!aplcen!haven!rutgers!att!cbnewsl!dfp
From: dfp@cbnewsl.ATT.COM (david.f.prosser)
Newsgroups: comp.lang.c
Subject: Re: cpp behavior
Message-ID: <2260@cbnewsl.ATT.COM>
Date: 13 Oct 89 04:47:15 GMT
References: <1077@m3.mfci.UUCP>
Reply-To: dfp@cbnewsl.ATT.COM (david.f.prosser)
Organization: AT&T Bell Laboratories
Lines: 60

In article <1077@m3.mfci.UUCP> karzes@mfci.UUCP (Tom Karzes) writes:
 >I have a couple of questions about correct cpp behavior.  I have tried
 >the following test on several different machines with pcc-derived compilers
 >(and presumably standard cpp's as well), and all give the same results:

 >% cat test1
 >#define M1()+++
 >M1()
 >#define M2+++
 >M2
 >% /lib/cpp test1
 ># 1 "test1"
 >+++
 >
 >++
 >% 

The old Reiser /lib/cpp "lost" the first character after the macro
name in an object-like definition looking to see if a "(" was there.
Usually this isn't a problem since it's almost always white space.
Of course, we did find out about the people who had lines like:

	#define LENGTH=14
	int array[LENGTH];

(We kept /lib/cpp fixed anyway. :-)

 >Here's a second test, which again gives the same results on several
 >different machines:

 >% cat test2
 >#define M1 123
 >#if M1 == 123
 >xxx
 >#endif
 >
 >#define M2() 456
 >#if M2() == 456
 >yyy
 >#endif
 >% /lib/cpp test2
 ># 1 "test2"
 >xxx
 >
 >test2: 9: syntax error
 > 456 == 456
 >yyy
 >#endif
 >% 

As you guessed, the same /lib/cpp also never correctly replaced
function-like macros on #if lines.  Again, usual programming never
found this bug.

This is similar to how the same preprocessor does not let you
define a function-like macro using the "-D" command line option:
The things you typically wanted and needed in the preprocessor
were done right and done fast with old /lib/cpp.

Dave Prosser