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 _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel