On 23/05/18 12:34, Petr Skočík wrote: > I don't know if the page is still relevant to this project but > I've posted a simpler and hopefully clearer report on this > bug at: https://savannah.nongnu.org/bugs/?group=tinycc > > I'm reposting here: > > #if-block bodies, when expanded as macro arguments, incorrect if #if argument > has a macro in it > > Example: > > #define PASTE_X(X) X > > PASTE_X( > BEFORE: > #if HAS_X //same for e.g.: 1*HAS_X+0+2 > int x; //this gets replaced by the value of HAS_X > #endif > AFTER: > ) > > (Compile with e.g., tcc -DHAS_X=42 c.c. The output is then `42` instead of > `BEFORE: int x; AFTER:` ) > > This bug only affects expanded #if-blocks -- if the block isn't passed to a > macro (variadic or not) > it expands OK.
Hmm, I don't think this is a bug - its simply undefined behaviour. From the C99 standard, 6.10.3 Macro replacement, sub-paragraph 11: "The sequence of preprocessing tokens bounded by the outside-most matching parentheses forms the list of arguments for the function-like macro. The individual arguments within the list are separated by comma preprocessing tokens, but comma preprocessing tokens between matching inner parentheses do not separate arguments. If there are sequences of preprocessing tokens within the list of arguments that would otherwise act as preprocessing directives, the behavior is undefined." > If the macro inside the argument to the #if is preceeded by `defined` or > enclosed in `defined()`, > the expansion works OK again. Hmm, that may be a little odd, but is an allowed implementation. ATB, Ramsay Jones _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
