When checking for integer overflow, you may often write tests like
p + i < p. This works fine if
i are unsigned integers, since any overflow in the addition
will cause the value to simply "wrap around." However, using this pattern when
p is a pointer is problematic because pointer overflow has
undefined behavior according to the C and C++ standards. If the addition
overflows and has an undefined result, the comparison will likewise be
undefined; it may produce an unintended result, or may be deleted entirely by an
To check whether an index
i is less than the length of an array,
simply compare these two numbers as unsigned integers:
i < ARRAY_LENGTH.
If the length of the array is defined as the difference between two pointers
i < p_end - ptr.
i is signed, cast it to unsigned
in order to guard against negative
i. For example, write
(size_t)i < p_end - ptr.
An invalid check for pointer overflow is most often seen as part of checking
whether a number
a is too large by checking first if adding the
ptr goes past the end of an allocation and then
checking if adding it to
ptr creates a pointer so large that it
overflows and wraps around.
In both of these checks, the operations are performed in the wrong order.
First, an expression that may cause undefined behavior is evaluated
ptr + i), and then the result is checked for being in range.
But once undefined behavior has happened in the pointer addition, it cannot
be recovered from: it's too late to perform the range check after a possible
While it's not the subject of this query, the expression
ptr + i <
ptr_end is also an invalid range check. It's undefined behavor in
C/C++ to create a pointer that points more than one past the end of an
The next example shows how to portably check whether an unsigned number is outside the
range of an allocation between