Re: [Tinycc-devel] bug: #if-block bodies, when expanded as macro arguments, incorrect if #if argument has a macro in it

[Ramsay Jones]

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