wave lexed_tokens sample gives an unexpected answer
Hello, I built the Wave preprocessing lib out of CVS head today using GCC 4.2.1 on Linux x86 box (openSUSE 10.3). I then built the lexed_tokens sample and ran it on the attached header file. The unexpected answer was how the 'defined' keyword was treated. I expected it to treat it as T_DEFINED, but it seems to return T_IDENTIFIER as shown by this output fragment: ... PP_IF (#370) at foo.h ( 4/ 1): >#if< SPACE (#393) at foo.h ( 4/ 4): > < IDENTIFIER (#381) at foo.h ( 4/ 5): >defined< SPACE (#393) at foo.h ( 4/12): > < IDENTIFIER (#381) at foo.h ( 4/13): >BAR< NEWLINE (#395) at foo.h ( 4/16): >\n< ... Leo #ifndef FOO_H #define FOO_H #if defined BAR #define BAZ #endif #endif /* FOO_H */
Leo,
I built the Wave preprocessing lib out of CVS head today using GCC 4.2.1 on Linux x86 box (openSUSE 10.3). I then built the lexed_tokens sample and ran it on the attached header file. The unexpected answer was how the 'defined' keyword was treated. I expected it to treat it as T_DEFINED, but it seems to return T_IDENTIFIER as shown by this output fragment:
... PP_IF (#370) at foo.h ( 4/ 1): >#if< SPACE (#393) at foo.h ( 4/ 4): > < IDENTIFIER (#381) at foo.h ( 4/ 5): >defined< SPACE (#393) at foo.h ( 4/12): > < IDENTIFIER (#381) at foo.h ( 4/13): >BAR< NEWLINE (#395) at foo.h ( 4/16): >\n< ...
That's (at least a documentaion) bug. The token T_DEFINED get's never generated and should be removed from the implementation. 'defined' has a special meaning to the preprocessor only and _is_ a identifier for the compiler (it's not a keyword). So the bottomline is that the lexed_tokens example behaves correctly, but I need to remove the T_DEFINED token-id from the implementation to avoid further confusion. Regards Hartmut
Hartmut Kaiser wrote:
Leo,
I built the Wave preprocessing lib out of CVS head today using GCC 4.2.1 on Linux x86 box (openSUSE 10.3). I then built the lexed_tokens sample and ran it on the attached header file. The unexpected answer was how the 'defined' keyword was treated. I expected it to treat it as T_DEFINED, but it seems to return T_IDENTIFIER as shown by this output fragment:
... PP_IF (#370) at foo.h ( 4/ 1): >#if< SPACE (#393) at foo.h ( 4/ 4): > < IDENTIFIER (#381) at foo.h ( 4/ 5): >defined< SPACE (#393) at foo.h ( 4/12): > < IDENTIFIER (#381) at foo.h ( 4/13): >BAR< NEWLINE (#395) at foo.h ( 4/16): >\n< ...
That's (at least a documentaion) bug. The token T_DEFINED get's never generated and should be removed from the implementation. 'defined' has a special meaning to the preprocessor only and _is_ a identifier for the compiler (it's not a keyword). So the bottomline is that the lexed_tokens example behaves correctly, but I need to remove the T_DEFINED token-id from the implementation to avoid further confusion.
OK. FYI, *C, A Reference Manual* calls 'defined' an operator in the context of #if and #elif. Leo
Leo,
I built the Wave preprocessing lib out of CVS head today using GCC 4.2.1 on Linux x86 box (openSUSE 10.3). I then built the lexed_tokens sample and ran it on the attached header file. The unexpected answer was how the 'defined' keyword was treated. I expected it to treat it as T_DEFINED, but it seems to return T_IDENTIFIER as shown by this output fragment:
... PP_IF (#370) at foo.h ( 4/ 1): >#if< SPACE (#393) at foo.h ( 4/ 4): > < IDENTIFIER (#381) at foo.h ( 4/ 5): >defined< SPACE (#393) at foo.h ( 4/12): > < IDENTIFIER (#381) at foo.h ( 4/13): >BAR< NEWLINE (#395) at foo.h ( 4/16): >\n< ...
That's (at least a documentaion) bug. The token T_DEFINED get's never generated and should be removed from the implementation. 'defined' has a special meaning to the preprocessor only and _is_ a identifier for the compiler (it's not a keyword). So the bottomline is that the lexed_tokens example behaves correctly, but I need to remove the T_DEFINED token-id from the implementation to avoid further confusion.
OK. FYI, *C, A Reference Manual* calls 'defined' an operator in the context of #if and #elif.
Yes you're right. That's exactly what I meant with 'has a special meaning for the pp only'. Wave doesn't return preprocessor specific tokens to the caller, so 'defined' has to be handled as a normal identifier. Regards Hartmut
participants (2)
-
Hartmut Kaiser -
Leo Davis