4
votes

Test ENV

  • Linux
  • Intel x86-64 GCC 8.2.1
  • Flags enabled: -Wextra -Wall -Wfloat-equal -Wundef -Wshadow -Winit-self -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wstrict-overflow=5 -Wwrite-strings -Waggregate-return -Wcast-qual -Wswitch-default -Wswitch-enum -Wconversion -Wunreachable-code -Wformat=2 -pedantic -pedantic-errors -Werror-implicit-function-declaration -Wformat-security -fstrict-overflow
  • sizeof(long) is 8.
  • sizeof(int) is 4.

Example 1, got a warning, good:

long x = 2147483647 * 3;

Example 2, no warning, not good:

long x = 2147483647U * 3U; // Suffix U

or

unsigned int a = 2147483647;
unsigned int b = 3;
long x = a*b;

Example 3, no warning, but work as expected:

long x = 2147483647L * 3L; // Suffix L

In the example 2, I know that it is a wrap-around instead of integer overflow, but these are those cases that the compiler are unable to warn about?

From the Standard:

(6.3.1.8)

Otherwise, the integer promotions are performed on both operands. Then the following rules are applied to the promoted operands:

If both operands have the same type, then no further conversion is needed. Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank.

Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type.

Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, then the operand with unsigned integer type is converted to the type of the operand with signed integer type.

Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed integer type.

(6.5):

If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its (type), the behavior is undefined.


Started using Clang with flag -fsanitize=unsigned-integer-overflow that helps a lot with undesired values from wrap-around. That is not an integer overflow, but not the intended value. Since GCC, until now does not support a warning like this, moving on to Clang.

2
FYI: In the terminology of the C standard, unsigned integers never overflow; they wrap-around.jamesdlin
In example two you multiply two unsigned integers and the result wrap-around then that result gets stored in a long.kingW3
The value 2147483645 was supose to be the wrap-around?Undefined Behavior

2 Answers

3
votes

Overflow of signed integers invokes undefined behavior, while unsigned integer overflow is well defined.

For unsigned integers, overflow occurs as if the values were computed modulo one more than the maximum value of the given type. Put another way, if the type is n bits wide, then only the low order n bits of the result are retained. This is not actually overflow but is referred to as wraparound.

This is spelled out in section 6.5p9:

The range of nonnegative values of a signed integer
type is a subrange of the corresponding unsigned integer type, and the representation of the same value in each type is the same. A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type.

Because this behavior is well defined, it doesn't make sense for the compiler to trigger a warning.

In the case of your second example:

long x = 2147483647U * 3U; 

The multiplication is done on unsigned types, so the mathematical result 6442450941 wraps around to 2147483645, which is within the range of a long. There's no overflow (just wraparound) and no out-of-range conversion, so no warning.

0
votes

Not GCC, but some static analyzer rules would warn about such "overflows".

For instance, both examples 1 & 2 would be flagged by MISRA C checker, because these overflow in expression with constants - which is indicative of programmer mistake. 2012 Rule 12.4: "Evaluation of constant expressions should not lead to unsigned integer wrap-around."

A more generic case is described by INT30-C in SEI CERT C Coding Standard, which advices to avoid any kind of overflow for secure applications and provides a list of automatic checkers that honor the rule.