[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] bug: #if-block bodies, when expanded as macro argumen
Re: [Tinycc-devel] bug: #if-block bodies, when expanded as macro arguments, incorrect if #if argument has a macro in it
Wed, 23 May 2018 22:18:30 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
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
> #define PASTE_X(X) X
> #if HAS_X //same for e.g.: 1*HAS_X+0+2
> int x; //this gets replaced by the value of HAS_X
> (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,
"The sequence of preprocessing tokens bounded by the outside-most matching
forms the list of arguments for the function-like macro. The individual
the list are separated by comma preprocessing tokens, but comma preprocessing
between matching inner parentheses do not separate arguments. If there are
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.