Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Integer operations must result in an integer value within the range of the integer type (that is, the resulting value is the same as the result produced by unlimited-range integers). Frequently, the range is more restrictive based restrictive depending on the use of the integer value, for example, as an index. Integer values can be verified by code review or by static analysis.

Integer overflow is undefined behavior, so a compiled program can do anything, including going off to play the Game of Life. Furthermore, a compiler may perform optimizations that assume an overflow will never occur, which can easily yield unexpected results. Compilers can optimize away if statements that check whether an overflow occurred. See recommendation MSC15-C. Do not depend on undefined behavior for an example.

Verifiably in-range operations are often preferable to treating out-of-range values as an error condition because the handling of these errors has been repeatedly shown to cause denial-of-service problems in actual applications. The quintessential example of this is the failure of the Ariane 5 launcher, which occurred because of an improperly handled conversion error that resulted in the processor being shut down [Lions 1996].

...

For saturation semantics, assume that the mathematical result of the computation is result. The value actually returned to the user is set out in the following table:

range Range of mathematical result result returned Mathematical Result

Result Returned

MAX < result

MAX

MIN <= result <= MAX

result

result < MIN

MIN

...

In modwrap semantics (also called modulo arithmetic), integer values "wrap round." That is, adding one to MAX produces MIN. This is the defined behavior for unsigned integers in the C Standard standard [ISO/IEC 9899:19992011], Section 6.2.5, "Types," paragraph 9. This is frequently the behavior of signed integers, as well. However, it is more sensible in many applications to use saturation semantics instead of modwrap semantics. For example, in the computation of a size (using unsigned integers), it is often better for the size to stay at the maximum value in the event of overflow rather than suddenly becoming a very small value.

Restricted Range Usage

Another tool Another technique for avoiding integer overflow is to use only half the range of signed integers. For example, when using an int, use only the range [INT_MIN/2, INT_MAX/2]. This has been a trick of the trade in Fortran for some time, and now that optimizing C compilers are becoming more sophisticated, it can be valuable in C.

Consider subtraction. If the user types the expression a - b, where both a and b are in the range [INT_MIN/2, INT_MAX/2], then the result will be in the range (INT_MIN, INT_MAX] for a typical two's complement machine.

...

Code Block
bgColor#ffcccc
langc

int i = /* Expression that evaluates to the value 32767 */;
/* ... */
if (i + 1 <= i) {
  /* handle overflow */
}
/* expression involving i + 1 */

...

Code Block
bgColor#ccccff
langc

long i = /* Expression that evaluates to the value 32767 */;
/* ... */
/* No test is necessary; i is known not to overflow. */
/* expression involving i + 1 */

...

LDRA tool suite

488 S

section

could

Could detect violations of this recommendation by flagging any comparison expression involving addition that could potentially overflow.

eg instead

 For example, instead of comparing

'

a + b < c

',

(where b and c are compile-time constants) and b > c, the code should compare

'

a < c - b

'

. (This assumes a, b, c are unsigned

ints

ints. Usually b is small and c is an upper bound such as INT_MAX.)

Tool

Version

Checker

Description

Section
Include Page
LDRA_V
LDRA_V
Section

Partially

Implementedsection

implemented.

Compass/ROSE

 

 

Section

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

...

ISO/IEC TR 24772 "FLC Numeric Conversion Errorsconversion errors"

Bibliography

ISO/IEC 9899:2011], Section 6.2.5, "Types"

[Lions 1996]

...