cpp behavior

david.f.prosser dfp at cbnewsl.ATT.COM
Fri Oct 13 14:47:15 AEST 1989


In article <1077 at m3.mfci.UUCP> karzes at 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



More information about the Comp.lang.c mailing list