Simple method to detect int overflow

Question 1

To detectint overflow/underflow in C, I use this code. What might be a simpler and more portable way of coding this (that is, fewer conditions)?

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();    }

Question 2

I think you're misunderstanding underflow ... or am I? Let's say, as an example, the smallest number afloat can represent is0.001.1.0 / 10000 would result in a value of0.0 because the actual value is too small.

Question 3

@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.

Question 4

If you just change from usingint to usingunsigned int, or better still,uint32_t andsize_t, you'll be able to do those checks after the operation. For signedints, 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.

Question 5

@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.

Question 6

From GCC 5, there arebuiltin functions to do this.

Question 7

It's not possible to avoid undefined behaviour by testing for it after the fact! If the addition overflows then there is already undefined behaviour here:

sum = a + b;

so attempting to test afterwards is too late. You have to test for possible overflowbefore you do a signed 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 here */    } else if (a < 0 && b < INT_MIN - a) {        /* handle underflow here */    }    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.

Update (2023) Several modern compilers now have built-in functions for arithmetic with overflow checking. For example, using GCC's__builtin_add_overflow, we could implementsafe_add like this:

int safe_add(int a, int b) {    int sum;    if (__builtin_add_overflow(a, b, &sum)) {        /* handle overflow or underflow here */    } else {        return sum;    }}

Question 8

§5.2.4.2.1 in theC99 standard definesINT_MIN to be the "minimum value for an object of typeint" andINT_MAX to be the "maximum value for an object of typeint".

Question 9

@Jamal Actually, with<limits>.std::numeric_limits<int>::min() andstd::numeric_limits<int>::max() to be precise.

Question 10

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.

Question 11

@Max: That would have undefined behaviour ifa + b overflowed, and undefined behaviour is what we are trying to avoid! (But also, even ifa + b were defined, your expression could not work, becausea + b is anint, and all values ofint are less than or equal toINT_MAX.)

Question 12

There is a use for separate cases in doing saturating arithmetic.

Question 13

Simpler method to detect int overflow...

The two simplest methods I know are:

Use theSafeInt library in C++
Use thesafe_iop library in C

SafeInt was written by David LeBlanc, and Microsoft uses it.safe_iop was written by ???, and Android uses it.

The next simplest method is to use a compiler intrinsic. Unfortunately, I have not seen many of them. I believe I saw some for GCC recently.

The neat thing about intrinsics are (1) they provide a familiar C function call and (2) they are not bound by the Undefined Behavior you are trying to avoid. That means an instrinsiccan perform the addition and the program will still be well defined, even it it overflows.

(In C/C++, if you perform the addition and it overflows, then the program is illegal. You are not allowed to perform the operation and then check the result).

The next simplest method is assembly and inline assembly. Again, its not bound by the Undefined Behavior you are trying to avoid in C/C++.

Assembly and inline assembly routines are the method I use. I work on mobile platforms and I have a library for i686, x86_64, ARM and MIPS.

I learned a long time ago its a pain in the butt to try and do this cross-platform in a well defined, portable and efficient manner from C, especially for some operations.

I was constantly checking results of compilations and starring at disassembled code to make sure the code generation was good. So I abandoned portable in the name of simplicity and efficiency.

Also seeHow to detect integer overflow in C/C++? on Stack Overflow.

Question 14

As of late 2018 there's a Boost library very similar to SafeInt:boost.org/doc/libs/1_74_0/libs/safe_numerics/doc/html/tutorial/…

Question 15

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.

Question 16

As typelong is only guaranteed to beat least the range ofint, converting tolong may not provide any additional range. Thus the problem is fundamentally the same forlong as forint. Same situation forlong long.

Question 17

While it's is technically true thatlong long is only guaranteed to be at least as long asint, I'm not aware of any platform that actually implementslong long using the same number of bytes asint. So in practice, this solution just works, plus it's much simpler.

Question 18

@SamuelLi Just because it works doesn't mean it's portable.

Question 19

@S.S.Anne While your statement is true, but since there are only a handful of platforms there and none is emerging in the near future, I'd say this is a portable solution for available platforms today and many years to come.

Question 20

@SamuelLi The ILP64 ABI of x86_64 has a 64-bitint,long, andlong long.

Question 21

Overflow and underflow can happen in two cases : either

Both negative numbers and sum becomes positive or
Both positive numbers and sum becomes negative.

Then you can use this logical expression:

     ((a<0)&&(b<0)&&(a+b>0)) || ((a>0)&&(b>0)&&(a+b<0))

or if you prefer integer arithmetics to logical expressions:

     (a<0)*(b<0)*(a+b>0) + (a>0)*(b>0)*(a+b<0)

In two complements one can be pedantic and just pick out the sign bit to do operations on, or even in hardware.

Question 22

That's not exactlyportable, given that you're invoking Undefined Behaviour and then attempting a test for it afterwards. This solution fails in systems with saturating arithmetic, for example.

Question 23

@TobySpeight : Yes you are right. I guess I haven't worked enough with those saturating arithmetics to think about it automatically. We can do some constant compile time tests from the start to determine that and use macros to decide if to compile our code or the saturated code.

Question 24

If you add along long to achar, you could still overflow with all positive numbers. I didn't downvote, just wanted to point this out.

Gareth Rees 50.1k3 gold badges130 silver badges211 bronze badges · Answer 1 · 2023-06-14 07:36:15Z