Clang not diagnosing invalid literals in subexpressions within a preprocessor conditional

[kyuupichan]

I cannot find anything that permits a compiler to accept the following (in either the C or C++ standards). Integer literals must have a type and a value in range for that type:

#if 0? 999999999999999999999999999999999999: 3
#endif

Clang accepts it even with -pedantic-errors. It seems that GCC, EDG and MSVC all reject it.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Neil Booth (kyuupichan)

I cannot find anything that permits a compiler to accept the following (in either the C or C++ standards). Integer literals must have a type and a value in range for that type:

#if 0? 999999999999999999999999999999999999: 3
#endif

Clang accepts it even with -pedantic-errors. It seems that GCC, EDG and MSVC all reject it.

[AaronBallman]

The issue doesn't seem to be about unevaluated contexts in general, just in subexpressions within a preprocessor conditional which are not evaluated when evaluating the conditional itself. e.g., Clang diagnoses this:

int x = sizeof(999999999999999999999999999999999999);
#if 999999999999999999999999999999999999
#endif

but does not diagnose this

#if 0 ? 999999999999999999999999999999999999 : 3
#endif

#if 1 || 999999999999999999999999999999999999
#endif

I suspect this happens because we never actually evaluate the value to begin with.

https://godbolt.org/z/ohWG8xc5r

[shafik]

In C++ clang is the only one not to diagnose: https://godbolt.org/z/sWEh3efYe

[kyuupichan]

@AaronBallman you might be right. It is, in general, necessary to examine the constant in some form in order to determine its type (i.e. signedness) as this affects the integer promotions and therefore the result of an expression, even though what value it has with that signedness is irrelevant.

[AaronBallman]

I don't think it's necessary, actually. Integer promotions don't apply because the preprocessor treats all integers as having type intmax_t or uintmax_t, which are both going to be at least as wide as int. And there's no way to inspect the type from the preprocessor (only once preprocessing has completed). So I don't think there's a correctness issue here regarding the semantics, just regarding the diagnostic behavior -- at least, I've yet to find a clever way to get Clang to demonstrate the wrong behavior.

[kyuupichan]

Integer promotions do matter - consider:

#if (0 ? 1 / 1U: -1) < 0
#error
#endif

The preprocessor needs to note the 1U otherwise it will #error. The integer promotions in the division, even though unevaluated, need to be done so that the result is considered unsigned. That in turn, in integer promotions in the conditional operator, turns the -1 into a large positive number.

[kyuupichan]

Incidentally that example shows something else wrong in Clang - it normally diagnoses the -1 becoming large and positive, but here it is suppressed for some reason, even though it is done because Clang doesn't #error.

[AaronBallman]

Integer promotions do matter - consider:

Integer promotions are what turn types narrower than int into int. e.g.,

void func(char c) {
  if (c > 0) {}
}

c is promoted from char to int before performing the comparison.

The preprocessor has no types narrower than int, so promotions definitely do not matter to the preprocessor. You're talking about the usual arithmetic conversions. Those do need to happen.

Oh fun, this behavior looks to be intentional:

llvm-project/clang/lib/Lex/PPExpressions.cpp

Line 348 in 369c773

if (ValueLive)

If the value isn't live, we suppress the diagnostic, because otherwise we'd issue diagnostic on dead branches for code like: #if 0 ? 124/0 : 42 This came from 86054a9.

Which, come to think of it, makes some sense. You may have code like:

#if __BITINT_MAXWIDTH__ > 128 && SomeMacro(0xFFFF'FFFF'FFFF'FFFF'1wb)
#endif

where you're checking for the max width of a bit-precise integer before trying to form a literal of a value bigger than the compiler can handle.

[kyuupichan]

The usual arithmetic conversions are precisely the integer promotions, as we're talking about preprocessor expressions where there are no complex, floating or imaginary types.

They involve precisely the cases where a signed value is forced to become unsigned.

And yes, the division by zero case you mention is precisely one where the evaluation must not be diagnosed, but the underlying conversions still have to be tracked.

GCC and my own preprocessor get this right, so it's quite doable. Clang just needs fixing in a few places.

[zygoloid]

The usual arithmetic conversions are precisely the integer promotions, as we're talking about preprocessor expressions where there are no complex, floating or imaginary types.

The usual arithmetic conversions take as input two expressions and convert them to a common type. Integer promotion takes as input a single expression and converts it to the smallest promoted type that can represent all the values of the source. They are not the same thing, even in the restricted world of preprocessor constant expressions: integer promotion never converts signed to unsigned, for example, but the usual arithmetic conversions can. But it doesn't really matter, given that neither integer promotions nor the usual arithmetic conversions are relevant for this issue.

I think the key point is that preprocessor constant expressions are supposed to behave as if they're treated as a C or C++ integer constant expression, except that all standard integer types are max-width for evaluation. And in that model, 0 ? 1 / 0 : 1 is a valid constant expression and 0 ? <overly large integer> : 1 is not. For example, in C++, the latter violates [lex.icon]/4.