Re: [Tinycc-devel] Preprocessor bug: macro eating directives and non nested nested expansions

[Jennifer Usher]

Jennifer
Sent from my iPad

> On Jun 17, 2022, at 6:05 AM, camel-cdr via Tinycc-devel 
> <tinycc-devel@nongnu.org> wrote:
> 
> Hi, I hope this is the correct place to report this:
> 
> 1)
> 
> #define EAT()
> #if 1
> EAT
> #endif
> 
> Results in the error "eat_endif.c:4: error: missing #endif", but the code 
> should be valid.
> 
> 2)
> 
> 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
> A(1)(1)(1)(1)
> 
> 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#6.10.3.4p4 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 recursive calls.
> 
> The same problem occurs with the following:
> 
> #define A0
> #define B0
> #define A1(x) x B##x(
> #define B1(x) x A##x(
> A1(1)1)1)1)1)0))
> 
> 
> 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/
> 
> Greetings,
> Olaf
> 
> _______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel