preprocessor issue #2

uj commented 2026年02月27日 13:29:49 +01:00

urs% cat /tmp/tt.c
#include <stdio.h>
#define STRINGIFY(x) #x
#define PARENT(x) STRINGIFY(x)
#define COMMA_ARG(a,b,c) a+b+c
int main(void) {
printf("Comma: %s\n", PARENT(COMMA_ARG(1,2,3)));
return 0;
}

urs% for c in gcc clang tcc nvc icx antcc ; do $c -E -std=c11 tt.c -o xx.i && echo -n $c" "; $c -dumpversion ; grep Comma: xx.i ; done
gcc 15
printf("Comma: %s\n", "1+2+3");
clang 17.0.6
printf("Comma: %s\n", "1+2+3");
tcc 0.9.28rc
printf("Comma: %s\n", "1+2+3");
nvc 26.1
printf("Comma: %s\n", "1+2+3");
icx 21.1.1
printf("Comma: %s\n", "1+2+3");
antcc 0.1.8
printf("Comma: %s\n", "1 + 2 + 3" );

urs% cat /tmp/tt.c #include <stdio.h> #define STRINGIFY(x) #x #define PARENT(x) STRINGIFY(x) #define COMMA_ARG(a,b,c) a+b+c int main(void) { printf("Comma: %s\n", PARENT(COMMA_ARG(1,2,3))); return 0; } urs% for c in gcc clang tcc nvc icx antcc ; do $c -E -std=c11 tt.c -o xx.i && echo -n $c" "; $c -dumpversion ; grep Comma: xx.i ; done gcc 15 printf("Comma: %s\n", "1+2+3"); clang 17.0.6 printf("Comma: %s\n", "1+2+3"); tcc 0.9.28rc printf("Comma: %s\n", "1+2+3"); nvc 26.1 printf("Comma: %s\n", "1+2+3"); icx 21.1.1 printf("Comma: %s\n", "1+2+3"); antcc 0.1.8 printf("Comma: %s\n", "1 + 2 + 3" );

lsof commented 2026年02月27日 15:34:58 +01:00

Token spacing is a known issue. I've been putting off fixing it because it seems fairly convoluted when nested macro expansions, token pasting etc are involved and I haven't yet set aside the time to think about the best way to implement it. GCC has a whole page about it

Token spacing is a known issue. I've been putting off fixing it because it seems fairly convoluted when nested macro expansions, token pasting etc are involved and I haven't yet set aside the time to think about the best way to implement it. [GCC has a whole page about it](https://gcc.gnu.org/onlinedocs/cppinternals/Token-Spacing.html)

lsof commented 2026年03月01日 11:20:12 +01:00

Should be fixed with 1ebf3669f9. Each raw token keeps track of whether it is preceded by whitespace and that is what is used when emitting preprocessed output/stringifying. Macros and macro argument expansions need special handling for their first token. Also there is a thing GCC calls paste avoidance: given #define PLUS +, stringifying PLUS+ gives "++" (because there is no whitespace in the replacement list), but when emitting the preprocessed output it should have a space, + +, so they aren't treated as a single token. There's edgecases regarding ## token pasting too, can't be 100% sure I'm accounting for every obscure thing. -E output is certainly much nicer to look at now at least.

Should be fixed with 1ebf3669f9. Each raw token keeps track of whether it is preceded by whitespace and that is what is used when emitting preprocessed output/stringifying. Macros and macro argument expansions need special handling for their first token. Also there is a thing GCC calls paste avoidance: given `#define PLUS +`, stringifying `PLUS+` gives `"++"` (because there is no whitespace in the replacement list), but when emitting the preprocessed output it should have a space, `+ +`, so they aren't treated as a single token. There's edgecases regarding ## token pasting too, can't be 100% sure I'm accounting for every obscure thing. `-E` output is certainly much nicer to look at now at least.