[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] Preprocessor bug: macro eating directives and non nes
Re: [Tinycc-devel] Preprocessor bug: macro eating directives and non nested nested expansions
Fri, 17 Jun 2022 06:41:13 -0700
Sent from my iPad
> On Jun 17, 2022, at 6:05 AM, camel-cdr via Tinycc-devel
> <firstname.lastname@example.org> wrote:
> Hi, I hope this is the correct place to report this:
> #define EAT()
> #if 1
> 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#18.104.22.168p4 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(
> 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