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