# Simpler method to detect int overflow

To detect int overflow/underflow in C, I use the below code.

What might be simpler and portable code? (that is: fewer tests)

Assume 2's complement and don't use wider integers.

int a,b,sum;
sum = a + b;
// out-of-range only possible when the signs are the same.
if ((a < 0) == (b < 0)) {
if (a < 0) {
// Underflow here means the result is excessively negative.
if (sum > b) UnderflowDetected();
}
else {
if (sum < b) OverflowDetected();
}

-
I think you're misunderstanding underflow ... or am I? Let's say, as an example, the smallest number a float can represent is 0.001. 1.0 / 10000 would result in a value of 0.0 because the actual value is too small. –  Fiddling Bits Dec 12 '13 at 0:44
@BitFiddlingCodeMonkey this is on integers - there are various wrap-around cases where the result of an addition does not fit in the same size integer. Sometimes it's called underflow when it's the sum of two negative numbers that doesn't fit. –  Michael Urman Dec 12 '13 at 1:01
If you just change from using int to using unsigned int, or better still, uint32_t and size_t, you'll be able to do those checks after the operation. For signed ints, overflow and underflow can't be detected after-the-fact because of undefined behaviour. And be warned: undefined behaviour can exhibit itself as anything from the program appearing to work properly right through to malware being installed on your machine and being used to steal your credit card information. –  Matt Dec 12 '13 at 12:10
@chux: No - I was merely pointing out that the method employed here (i.e. do an add and then see if an overflow occurred) is valid only on unsigned integers. For signed integers it is never valid because overflow of signed integers is inherently undefined in the language. –  Matt Dec 12 '13 at 15:52
From GCC 5, there are builtin functions to do this. –  o11c Jun 17 at 23:09

Your code doesn't work: if the addition overflows then there is undefined behaviour here:

sum = a + b;


so your test is too late. You have to test for possible overflow before you do the addition. (If you're puzzled by this, read Dietz et al. (2012), "Understanding Integer Overﬂow in C/C++". Or even you're not puzzled: it's an excellent paper!)

If it were me, I'd do something like this:

#include <limits.h>

int safe_add(int a, int b) {
if (a > 0 && b > INT_MAX - a) {
/* handle overflow */
} else if (a < 0 && b < INT_MIN - a) {
/* handle underflow */
}
return a + b;
}


but I'm not entirely sure what the point of having separate cases for overflow and underflow is.

I also use Clang's -fsanitize=undefined when building for test.

-
§5.2.4.2.1 in the C99 standard defines INT_MIN to be the "minimum value for an object of type int" and INT_MAX to be the "maximum value for an object of type int". –  Gareth Rees Dec 11 '13 at 23:20
Yes, that's right. Typical values are INT_MIN = −2^32 = −2147483648 and INT_MAX = 2^32 − 1 = 2147483647, but the values can vary depending on your processor and compiler, so the only way to make code portable is to use the macros. –  Gareth Rees Dec 11 '13 at 23:27
@Jamal Actually, with <limits>. std::numeric_limits<int>::min() and std::numeric_limits<int>::max() to be precise. –  Yuushi Dec 12 '13 at 0:16
It's worth pointing out that integer overflow and underflow are undefined only for SIGNED types. For unsigned integers, overflow safely occurs as modulo arithmetic. –  Matt Dec 12 '13 at 12:02
@Max: That would have undefined behaviour if a + b overflowed, and undefined behaviour is what we are trying to avoid! (But also, even if a + b were defined, your expression could not work, because a + b is an int, and all values of int are less than or equal to INT_MAX.) –  Gareth Rees Dec 13 '13 at 13:36

Why not use a long to hold the result of the calculation? Then the long can be checked against the (int) MAX and MIN values to see if overflow or underflow occurred? If no violations have occurred, then the result can safely be re-cast back to an (int).

Or, is this too simple and I'm missing something very fundamental? One thing that I HAVE omitted is the possibility that the long will also overflow.

-
As type long is only guaranteed to be at least the range of int, converting to long may not provide any additional range. Thus the problem is fundamentally the same for long as for int. Same situation for long long. –  chux Jul 6 '14 at 17:18