macros again

[borophyll]

Sorry for my perverse interest in the C preprocessor, but I have a
question about a subtle matter. Yesterday, Eric brought up a point
about the following case, indicating how preprocessing input should be
treated as tokens rather than text. He gave this example

#define A *
#define B /

B* Not a comment A/

While GCC produces the preprocessor output

/ * Not a comment */

This generates 6 tokens. Would it be perfectly valid if I wrote a
preprocessor implementation that would produces 7 tokens as such

/ * Not a comment * /

since technically A and / are separate tokens before being
preprocessed. While GCC seems to combine these two tokens into one, I
guess technically there is nothing wrong with this, since */ is an
invalid token at this stage anyway.

regards, B

 

[Army1987]

Sorry for my perverse interest in the C preprocessor, but I have a
question about a subtle matter. Yesterday, Eric brought up a point
about the following case, indicating how preprocessing input should be
treated as tokens rather than text. He gave this example

#define A *
#define B /

B* Not a comment A/

While GCC produces the preprocessor output

/ * Not a comment */

This generates 6 tokens. Would it be perfectly valid if I wrote a
preprocessor implementation that would produces 7 tokens as such

/ * Not a comment * /

since technically A and / are separate tokens before being
preprocessed. While GCC seems to combine these two tokens into one, I
guess technically there is nothing wrong with this, since */ is an
invalid token at this stage anyway.

I think so, but it would be less confusing if it added whitespace
to show the token boundary.
Compare with
#define PLUS +
i+PLUS

it must expand in i+ +, which is a valid sequence because I could
write i+PLUS 5.
If the output of the preprocessor was text, it couldn't be i++
because that's two tokens, i ++, they should be three, i + +.