To detect int 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();  
  • \$\begingroup\$ 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. \$\endgroup\$ Dec 12, 2013 at 0:44
  • 2
    \$\begingroup\$ @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. \$\endgroup\$ Dec 12, 2013 at 1:01
  • 3
    \$\begingroup\$ 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. \$\endgroup\$
    – Matt
    Dec 12, 2013 at 12:10
  • 2
    \$\begingroup\$ @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. \$\endgroup\$
    – Matt
    Dec 12, 2013 at 15:52
  • 2
    \$\begingroup\$ From GCC 5, there are builtin functions to do this. \$\endgroup\$
    – o11c
    Jun 17, 2015 at 23:09

4 Answers 4


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 overflow before you do a signed addition. (If you're puzzled by this, read Dietz et al. (2012), "Understanding Integer Overflow 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.

  • 1
    \$\begingroup\$ § 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". \$\endgroup\$ Dec 11, 2013 at 23:20
  • 1
    \$\begingroup\$ @Jamal Actually, with <limits>. std::numeric_limits<int>::min() and std::numeric_limits<int>::max() to be precise. \$\endgroup\$
    – Yuushi
    Dec 12, 2013 at 0:16
  • 2
    \$\begingroup\$ 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. \$\endgroup\$
    – Matt
    Dec 12, 2013 at 12:02
  • 2
    \$\begingroup\$ @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.) \$\endgroup\$ Dec 13, 2013 at 13:36
  • 1
    \$\begingroup\$ There is a use for separate cases in doing saturating arithmetic. \$\endgroup\$ Jul 15, 2017 at 15:59

Simpler method to detect int overflow...

The two simplest methods I know are:

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 instrinsic can 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 see How to detect integer overflow in C/C++? on Stack Overflow.


Overflow and underflow can happen in two cases : either

  1. Both negative numbers and sum becomes positive or
  2. 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.

  • 2
    \$\begingroup\$ That's not exactly portable, 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. \$\endgroup\$ Sep 19, 2017 at 10:04
  • \$\begingroup\$ @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. \$\endgroup\$ Sep 19, 2017 at 10:29
  • 1
    \$\begingroup\$ If you add a long long to a char, you could still overflow with all positive numbers. I didn't downvote, just wanted to point this out. \$\endgroup\$ Jan 10 at 20:04

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.

  • 4
    \$\begingroup\$ 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. \$\endgroup\$ Jul 6, 2014 at 17:18
  • \$\begingroup\$ While it's is technically true that long long is only guaranteed to be at least as long as int, I'm not aware of any platform that actually implements long long using the same number of bytes as int. So in practice, this solution just works, plus it's much simpler. \$\endgroup\$
    – Samuel Li
    Mar 25, 2019 at 5:29
  • \$\begingroup\$ @SamuelLi Just because it works doesn't mean it's portable. \$\endgroup\$
    – S.S. Anne
    Jan 22, 2020 at 12:18
  • \$\begingroup\$ @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. \$\endgroup\$
    – Samuel Li
    Jan 23, 2020 at 15:53
  • 1
    \$\begingroup\$ @SamuelLi The ILP64 ABI of x86_64 has a 64-bit int, long, and long long. \$\endgroup\$
    – S.S. Anne
    Jan 23, 2020 at 16:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.