karzes@mfci.UUCP (Tom Karzes) (10/13/89)
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 #define M3()=== M3() #define M4=== M4 % /lib/cpp test1 # 1 "test1" +++ ++ === = % The results for M1 and M3 were what I expected, but I also would have expected the results for M2 to be identical to the results for M1, and the results for M4 to be identical to the results for M3. Note that there appears to be something special about =, since cpp eats two of them. For other characters it only eats one. But why should it eat any? Please try this on your own machine before responding (if for no other reason than to see if it does the same thing). 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 #define M3(x) x #if M3(789) == 789 zzz #endif % /lib/cpp test2 # 1 "test2" xxx test2: 9: syntax error 456 == 456 yyy #endif test2: 14: syntax error 789 == 789 zzz #endif test2: 15: missing endif % The M1 case did what I expected, i.e., it expanded M1, then evaluated 123 == 123, which resulted in a value of 1, so xxx was passed through. However, for both the M2 and M3 cases it appears that the macro was expanded, but rather than consuming the results, it instead placed them into the output, and forgot that it was processing an #if directive. This seems like a clear bug to me. Even if there is some rule about only using unparameterized macros in #if expressions (which seems stupid), I would have expected a sane error message. Please try this on your own machine before responding (if for no other reason than to see if it does the same thing).
dfp@cbnewsl.ATT.COM (david.f.prosser) (10/13/89)
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