Signed integer overflow is undefined behavior (see undefined behavior 36 in Annex J of C11 [ISO/IEC 9899:2011]). This means that implementations have a great deal of latitude in how they deal with signed integer overflow.
...
For these reasons, it is important to ensure that operations on signed integers do no result in overflow. (See MSC15-C. Do not depend on undefined behavior.) Of particular importance are operations on signed integer values that originate from untrusted sources and are used in any of the following ways:
...
The following sections examine specific operations that are susceptible to integer overflow. When operating on small integer types (smaller than int), integer promotions are applied. The usual arithmetic conversions may also be applied to (implicitly) convert operands to equivalent types before arithmetic operations are performed. Make sure you understand integer conversion rules before trying to implement secure arithmetic operations. (See INT02-C. Understand integer conversion rules.)
| Anchor | ||||
|---|---|---|---|---|
|
Addition
Addition is between two operands of arithmetic type or between a pointer to an object type and an integer type for rules about adding a pointer to an integer. (See ARR37-C. Do not add or subtract an integer to a pointer to a non-array object and ARR38-C. Do not add or subtract an integer to a pointer if the resulting value does not refer to a valid array element.) Incrementing is equivalent to adding one.
...
This compliant solution works only on architectures that use two's complement representation. Although most modern platforms use two's complement representation, it is best not to introduce unnecessary platform dependencies. (See MSC14-C. Do not introduce unnecessary platform dependencies.) This solution can also be more expensive than a postcondition test, especially on RISC CPUs.
...
Subtraction is between two operands of arithmetic type, two pointers to qualified or unqualified versions of compatible object types, or a pointer to an object type and an integer type. See ARR36-C. Do not subtract or compare two pointers that do not refer to the same array, ARR37-C. Do not add or subtract an integer to a pointer to a non-array object, and ARR38-C. Do not add or subtract an integer to a pointer if the resulting value does not refer to a valid array element for information about pointer subtraction. Decrementing is equivalent to subtracting one.
...
This compliant solution only works on architectures that use two's complement representation. Although most modern platforms use two's complement representation, it is best not to introduce unnecessary platform dependencies. (See MSC14-C. Do not introduce unnecessary platform dependencies.)
Compliant Solution (General)
...
The compliant solution uses a static assertion to ensure that the overflow detection will succeed. See DCL03-C. Use a static assertion to test the value of a constant expression for a discussion of static assertions.
...
Tool | Version | Checker | Description | ||||||
|---|---|---|---|---|---|---|---|---|---|
| 43 D | Partially implemented. | |||||||
Fortify SCA | V. 5.0 | Can detect violations of this rule with CERT C Rule Pack. Specifically, it checks to ensure that the operand of a unary negation is compared to the type's minimum value immediately before the operation. | |||||||
| PRQA QA·CQA-C |
| Fully implemented |
...
ISO/IEC TR 17961 (Draft) Overflowing signed integers [intoflow]
ISO/IEC TR 24772 "XYY Wrap-around error"
MITRE CWE: CWE-129, "Unchecked array indexing"
MITRE CWE: CWE-190, "Integer overflow (wrap or wraparound)"
Bibliography
[Dowd 2006] Chapter 6, "C Language Issues" ("Arithmetic boundary conditions," pp. 211–223)
[Seacord 2005] Chapter 5, "Integers"
[Viega 2005] Section 5.2.7, "Integer overflow"
[VU#551436]
[Warren 2002] Chapter 2, "Basics"
...