Overflow in constant expressions not caught

[llvmbot]

Bugzilla Link	2729
Resolution	FIXED
Resolved on	Jan 16, 2014 14:53
Version	unspecified
OS	NetBSD
Reporter	LLVM Bugzilla Contributor
CC	@chengniansun,@efriedma-quic,@zygoloid,@rjmccall,@RealLitb

Extended Description

Constraint 6.6p4 in C99 requires constant expressions evaluate to values within the range of their type. The following violation of that constraint is accepted in pedantic-errors mode.

#include <limits.h>

enum { ns = -INT_MIN }; /* Overflow. */

[efriedma-quic]

I don't think the standard actually requires the behavior you're proposing; clang's current behavior to evaluate ns to INT_MIN, which is a "constant that is in the range of representable values for its type".

That said, we probably should warn anyway.

[llvmbot]

You're right it doesn't require it if the implementation declares that signed integer overflow has well-defined wrapping behaviour. Is that clang's stance for C? I don't think it is.

[llvmbot]

Sorry Eli you're right, it's just u.b.

I think as a QOI issue though all easily-caught UB should be diagnosed, even if some well-defined meaning (such as wrapping) is assigned. In compile-time expression evaluation I feel all UB should be a hard error, but that's just a personal preference.

[llvmbot]

I agree. Unless the implementation burden to detect is high, there is plenty of value in allowing the user to get the warning, even if it is off by default.

[llvmbot]

There are other cases where Clang fails to report the overflow of a compile time value assignment. GCC does warn.

$ cat a.cpp
int a = 999 * 999 * 999 * 999;

$ clang -Wall -fsyntax-only a.cpp
$ gcc -fsyntax-only a.cpp
a.cpp:1: warning: integer overflow in expression

$ cat a.cpp
int a = 999999999999999;

$ clang -Wall -fsyntax-only a.cpp
$ gcc -fsyntax-only a.cpp
a.cpp:1: warning: integer constant is too large for ‘long’ type
a.cpp:1: warning: overflow in implicit constant conversion

[RealLitb]

I think requires a diagnostic in C++0x (as of n3225) because the overflow renders the expression a non-constant-expression. The value INT_MIN-1 can't be represented as an int, but will, on two's complement, compute to value INT_MAX.

There seems to be no clear statement in C++0x as to whether enumerators are unevaluated operands (I think that this is the intention, though). Clear statements however are made about "sizeof(char[INT_MIN-1])" and similar. These operands are unevaluated, so 5[expr]p4 does not apply to them.

I think the following rules is what the C++03 and C++0x Standard seem to state:

• Cases where constant expressions are required and where an overflow occurs in are diagnosed in C++0x. C++03 only requires a diagnostic for expressions that are evaluated, but I think that was an issue with C++03. So I think one should diagnose it in C++03 mode too.
• Cases where a constant expression is not required and where the overflow occurs in an unevaluated operands are not diagnosed and do not result in undefined behavior.
• Cases where constant expressions are not required and where the overflow occurs in an evaluated expression results in undefined behavior.

(just noticed I used INT_MIN-1 above, but I would think same applies to -INT_MIN. The negation of INT_MIN is naturally the positive absolute value of it, which int cannot represent).

[RealLitb]

[...]
I think the following rules is what the C++03 and C++0x Standard seem to state:

• Cases where constant expressions are required and where an overflow occurs in
  are diagnosed in C++0x. C++03 only requires a diagnostic for expressions that
  are evaluated, but I think that was an issue with C++03. So I think one should
  diagnose it in C++03 mode too.
• Cases where a constant expression is not required and where the overflow
  occurs in an unevaluated operands are not diagnosed and do not result in
  undefined behavior.
• Cases where constant expressions are not required and where the overflow
  occurs in an evaluated expression results in undefined behavior.

Sorry, I missed one twist: C++03 requires a diagnostic for cases where a constant expression is used in an evaluated expression that contains an overflow. C++0x does not do so anymore but states it's undefined behavior. So the following is UB in C++0x, but needs to be diagnosed in C++03. Examples:

// #​1: INT_MIN-1 is an evaluated overflowing expression.
// UB in C++0x, ill-formed without UB in C++03 (because INT_MIN-1 is a
// constant expression in C++03).
int a = INT_MIN-1;

// #​2: Unevaluated expression overflows in a case where no constant expression
// is required. No diagnostic in C++0x, unsure about C++03.
int a = sizeof(INT_MIN-1);

// #​3: Unevaluated expression overflows in a case where a constant expression
// is required -> Ill-formed in C++0x, possibly also in C++03 (assuming
// defect in C++03).
int x = sizeof(char[INT_MIN-1]);

// #​4: Evaluated non-constant expression overflow:
// Undefined in both C++03 and C++0x.
int f() { return INT_MIN; }
int a = f()-1;

[efriedma-quic]

Umm, what exactly are you citing in the standard? As far as I can tell, the situation for C++ is exactly then same as that for C99.

[RealLitb]

Umm, what exactly are you citing in the standard? As far as I can tell, the
situation for C++ is exactly then same as that for C99.

#​1 is UB because of 5/4 in n3225.

#​2 is alright it seems. The expression is not evaluated, and there is no text saying anything about what happens (the value is not needed anyway). Only the type of the expression is used by sizeof.

#​3 is ill-formed because of 5.19/2 bullet6 in n3225

#​4 is UB because of 5/4 in n3225 too.

GCC seems to handle this according to the above spec references.

[RealLitb]

Umm, what exactly are you citing in the standard? As far as I can tell, the
situation for C++ is exactly then same as that for C99.

#​1 is UB because of 5/4 in n3225.

#​2 is alright it seems. The expression is not evaluated, and there is no text
saying anything about what happens (the value is not needed anyway). Only the
type of the expression is used by sizeof.

#​3 is ill-formed because of 5.19/2 bullet6 in n3225

#​4 is UB because of 5/4 in n3225 too.

GCC seems to handle this according to the above spec references.

Just found the relevant issue and resolution here: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#695

[llvmbot]

*** Bug llvm/llvm-bugzilla-archive#12659 has been marked as a duplicate of this bug. ***

[llvmbot]

I believe this feature request is covered by r173377; please confirm.

[chengniansun]

I think the bug is still there. I have the following code

///////////////////// clang-constant-overflow.c ////////////
char g = 0x8FL;
/////////////////////// end ///////////////////////////////

I use the following command to compile it
$clang-trunk -Wall -Wextra -c -pedantic -std=c11 clang-constant-overflow.c
$cat clang-constant-overflow.c
char g = 0x8FL;
$clang-trunk --version
clang version 3.5 (trunk 198918)
Target: x86_64-unknown-linux-gnu
Thread model: posix

[zygoloid]

I think the bug is still there. I have the following code

char g = 0x8FL;

With -Weverything, I get:

:1:10: warning: implicit conversion changes signedness: 'long' to 'char' [-Wsign-conversion]
char g = 0x8fL;
~ ^~~~~

Anyway, there's no overflow in this code; there's a conversion from 'long' to 'char', which has an implementation-defined result, which for us is a 2s complement reduction.