Overflow is possible only when both numbers have the same sign. If both are positive, then you have overflow if mathematically A + B > LLONG_MAX
, or equivalently B > LLONG_MAX - A
. Since the right hand side is non-negative, the latter condition already implies B > 0
. The analogous argument shows that for the negative case, we also need not check the sign of B
(thanks to Ben Voigt for pointing out that the sign check on B
is unnecessary). Then you can check
if (A > 0) {
return B > (LLONG_MAX - A);
}
if (A < 0) {
return B < (LLONG_MIN - A);
}
return false;
to detect overflow. These computations cannot overflow due to the initial checks.
Checking the sign of the result of A + B
would work with guaranteed wrap-around semantics of overflowing integer computations. But overflow of signed integers is undefined behaviour, and even on CPUs where wrap-around is the implemented behaviour, the compiler may assume that no undefined behaviour occurs and remove the overflow-check altogether when implemented thus. So the check suggested in the comments to the question is highly unreliable.