[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Tinycc-devel] Re : Preprocessor bug: macro eating directives and non n
david . koch
[Tinycc-devel] Re : Preprocessor bug: macro eating directives and non nested nested expansions
Fri, 17 Jun 2022 15:15:58 +0200 (CEST)
> ...that rely on this behavior, e.g.: http://www.kotha.net/bfi/
OMFG, you know it reminds me ?
That : https://www.youtube.com/watch?v=dQppUxTpdzU
----- Mail d'origine -----
De: camel-cdr via Tinycc-devel <email@example.com>
Cc: camel-cdr <firstname.lastname@example.org>
Envoyé: Fri, 17 Jun 2022 14:30:30 +0200 (CEST)
Objet: [Tinycc-devel] Preprocessor bug: macro eating directives and non nested
Hi, I hope this is the correct place to report this:
Results in the error "eat_endif.c:4: error: missing #endif", but the code
should be valid.
This one is more complicated and not technically a bug, although I don't think
this behavior is intended.
#define A(x) x B
#define B(x) x A
The standard say that it's implementation defined if in the above code the
macro expansions are nested or not. (see
https://port70.net/~nsz/c/c11/n1570.html#126.96.36.199p4 and "When a fully
expanded..." in Annex J)
So an implementation could expand the above either to "1 1 A(1)(1)..." or "1 1
1 1 A".
gcc, clang, tcc and all otherwise valid preprocessor implementation I know of
expand it to "1 1 1 1 A", which is great for preprocessor meta programming.
But the problem is, whiles tcc expands the macros as though the expansion isn't
nested, this isn't reflected in the tcc code.
Meaning, if instead of 4 iterations you have e.g. 20000 of them tcc segfaults,
and the backtrace indicates that it's a stack overflow because of too many
The same problem occurs with the following:
#define A1(x) x B##x(
#define B1(x) x A##x(
This might sound a bit contrived, but there are preprocessor meta programming
models that rely on this behavior, e.g.: http://www.kotha.net/bfi/
Tinycc-devel mailing list