Logical AND (&&) does not short-circuit correctly in #if

Question

For code:

#if defined(FOO) && FOO(foo)
    #error "FOO is defined."
#else
    #error "FOO is not defined."
#endif

MSVC 19.38 prints:

<source>(1): warning C4067: unexpected tokens following preprocessor directive - expected a newline
<source>(4): fatal error C1189: #error:  "FOO is not defined."

ICX 2024.0.0 and Clang 18.1 prints:

<source>:1:21: error: function-like macro 'FOO' is not defined
    1 | #if defined(FOO) && FOO(foo)
      |                     ^
<source>:4:6: error: "FOO is not defined."
    4 |     #error "FOO is not defined."
      |      ^
2 errors generated.

GCC 14.1 prints:

<source>:1:24: error: missing binary operator before token "("
    1 | #if defined(FOO) && FOO(foo)
      |                        ^
<source>:4:6: error: #error "FOO is not defined."
    4 |     #error "FOO is not defined."
      |      ^~~~~
Compiler returned: 1

Why does every compiler but MSVC print an error about an undefined macro when FOO is not defined (although MSVC prints a warning too)? Is there some special semantic that I am not seeing here?

FOO(foo) should not be evaluated if defined(FOO) evaluates to false.

Margertmargery

This is a problem for C23's __has_include and similar macros. And was raised by a reviewer on the CodeReview website. – Margertmargery

One way to think about it is that even though the second operand may not be evaluated, it still has to be parsed successfully, and the syntax rules are different in the preprocessor than in C itself. The "short circuit" behavior in C is really about side effects that the second operand expression may have, and this is irrelevant to the preprocessor because there, expressions don't ever have side effects. – Ahab

@Margertmargery – When you wrote when FOO is not undefined, you meant "when FOO is not defined", right? – Carrero

@Carrero Yes. FIxed. – Margertmargery

Answer 1

If FOO is not defined (or is defined but not as a function-like macro), then FOO(foo) is a syntax error.

The #if directive expects an integer constant expression to follow it (including expressions of the form "defined identifier"). Since FOO(foo) can't be expanded due to FOO not being defined, this is not an integer constant expression.

You would get a similar error for something like this:

int main()
{
    int x = some_valid_expression && undeclared_identifier;
    return 0;
}

To do what you want, you need to break up the #if directive into multiple ones:

#if defined(FOO)
    #if FOO(foo)
        #error "FOO is defined and non-zero."
    #else
        #error "FOO is zero."
    #endif
#else
    #error "FOO is not defined."
#endif

Argumentation

Interesting. How then do I write #if defined(__has_include) && __has_include(<stdbit.h>) in a manner that wouldn't cause compilation failure if the macro __has_include was not defined? – Margertmargery

@Harith: Use nested #if directives. – Lascar

@Harith: The C23 draft standard has an 'EXAMPLE 2' that illustrates: /* Fallback for compilers not yet implementing this feature. */ — #ifndef __has_c_attribute — #define __has_c_attribute(x) 0 — #endif /* __has_c_attribute */ — #if __has_c_attribute(fallthrough) — … — #endif. A similar operation could be used for __has_include (and __has_embed). – Denbighshire

Answer 2

Preprocessor directives are solved at the preprocessor stage. This is, before actual C compilation starts. And this means the expression must be interpreted and evaluated as the file is read, not when the program is executed.

This means that the preprocessor tries to check the expression you have stated in the directive by interpreting it, not by executing it. As you have been told in another answer, if the macro is not defined, then FOO(something) is a preprocessor syntax error. Let's say you had said, instead:

#if defined(A) && FOO(something)

As the two expressions around the && operator must be interpreted, in case FOO() was a macro, it will be expanded and then interpreted, before evaluating the expression. I cannot infer the implications of evaluating the right side of a boolean expression, based on the results of the left side, because at preprocessor time, everything is static (no changes result from evaluating/not-evaluating a preprocessor expression). There are not side effects in the preprocessor, so both parts will have to be interpreted to compose the expression tree.... how the preprocessor evaluates the expression is up to the preprocessor designer.

Short circuiting affects execution (this is, at runtime) and is only visible if one of the sides of the && operator has lateral effects. This is not a matter for the preprocessor.

Quixote