Range of Integers and Overflow

On June 4, 1996, the Ariane 5 rocket—a flagship project of the European Space Agency—exploded 37 seconds after launch. The 10-year, $7 billion development program was destroyed in an instant. The cause? A 64-bit floating-point number was converted to a 16-bit signed integer. The velocity value exceeded 32,767, the conversion overflowed, and the guidance system received garbage data. The rocket swerved violently and self-destructed.

This wasn't a hardware failure. It wasn't bad luck. It was integer overflow—a predictable, preventable bug that occurs when a calculation exceeds the maximum (or goes below the minimum) value representable in a given integer type.

Understanding integer ranges and overflow behavior is not optional knowledge for serious engineers. It's foundational to writing correct, secure software.

Before we can understand overflow, we must have absolute clarity on the ranges that different integer types can represent. Every integer type has a finite range determined by its bit width.

The mathematical formulas:

For an n-bit integer:

Important named constants:

In C/C++, you'll frequently encounter these named constants (defined in <limits.h> or <climits>):

• CHAR_MAX, CHAR_MIN — 8-bit: 127 and -128 (or 255 and 0 for unsigned char)
• SHRT_MAX, SHRT_MIN — 16-bit: 32,767 and -32,768
• INT_MAX, INT_MIN — 32-bit: 2,147,483,647 and -2,147,483,648
• LLONG_MAX, LLONG_MIN — 64-bit: 9,223,372,036,854,775,807 and -9,223,372,036,854,775,808

Memorization tips:

• $2^{10} \approx 1000$ (actually 1024, ~3% error)
• 32-bit signed max: ~2.1 billion (think "two billion")
• 64-bit signed max: ~9.2 quintillion (think "nine quintillion")
• Unix epoch overflow in 32-bit signed: January 19, 2038 (the "Y2K38" problem)

Integer overflow occurs when the result of an arithmetic operation exceeds the range of the integer type being used. There are two directions:

• Overflow (positive overflow): Result exceeds the maximum representable value
• Underflow (negative overflow): Result goes below the minimum representable value

The fundamental problem:

When you add 1 to the maximum value of an integer type, something must happen—but there's no bit pattern available to represent the correct result. The outcome depends on:

1. Whether the type is signed or unsigned
2. The language/compiler being used
3. Sometimes, compiler optimization settings

The behavior of overflow differs fundamentally between signed and unsigned integers. This distinction is critical for writing correct code.

Why is signed overflow undefined?

This might seem strange—why would the C standard leave behavior undefined rather than specifying wraparound (which is what the hardware does)?

1. Optimization opportunities: If the compiler can assume overflow never happens, it can perform powerful optimizations. For example:

   • x + 1 > x can be optimized to true (if we assume no overflow)
   • Loop bounds analysis becomes simpler
   • Algebraic simplifications become possible

2. Historical diversity: Early machines used different signed representations (sign-magnitude, one's complement). Undefined behavior allowed portability across these systems.

3. Detection opportunities: By not defining the behavior, implementations can choose to trap (crash) on overflow, enabling debugging.

The practical reality:

Most hardware performs two's complement wraparound for signed overflow, just like unsigned. But relying on this is dangerous because:

• Optimizers can transform code based on the "no overflow" assumption
• Next compiler version might optimize differently
• Your code becomes non-portable

A powerful mental model for understanding overflow is the number circle (or number wheel). Instead of imagining integers on a line extending to infinity, visualize them arranged in a circle.

8-bit unsigned number circle:

                    0
               255     1
              254      2
             253      3
             ...     ...
             129      127
                 128

Incrementing moves clockwise. Decrementing moves counter-clockwise. When you increment 255, you wrap around to 0.

8-bit signed number circle (two's complement):

                    0
                -1     1
              -2     2
             -3     3
             ...     ...
            -127     127
                 -128

Notice that -128 and 127 are adjacent. Incrementing 127 crosses into -128—the wraparound point.

The key insight:

Both signed and unsigned share the same circle (the same 256 bit patterns for 8-bit). The difference is only in where we cut the circle open to assign names:

• Unsigned: cut at the transition from 255 to 0
• Signed: cut at the transition from 127 to -128

When does subtraction overflow?

For unsigned: a - b overflows (underflows) when b > a. The result wraps around from 0 to the maximum.

For signed: a - b overflows when:

• a > 0, b < 0, and a - b exceeds max positive (positive overflow)
• a < 0, b > 0, and a - b goes below min negative (negative overflow)

When does multiplication overflow?

Multiplication can overflow even with relatively small operands:

• 50000 × 50000 = 2,500,000,000 — exceeds 32-bit signed max (~2.1 billion)
• 70000 × 70000 = 4,900,000,000 — also exceeds 32-bit unsigned max (~4.3 billion)

When does addition overflow?

For unsigned: a + b overflows when a + b ≥ 2^n For signed: a + b overflows when both have the same sign and the result has the opposite sign

Different programming languages handle integer overflow in fundamentally different ways. Understanding your language's behavior is essential.

Language deep-dive: Rust's approach

Rust exemplifies a thoughtful approach to overflow:

// Standard operators panic in debug mode, wrap in release mode
let x: u8 = 255;
let y = x + 1;  // Panic in debug! Wraps to 0 in release.

// Explicit overflow handling methods
let wrapped = x.wrapping_add(1);    // Always wraps: 0
let saturated = x.saturating_add(1); // Clamps: 255
let checked = x.checked_add(1);      // Returns Option: None
let (result, overflow) = x.overflowing_add(1);  // Returns (value, bool)

This forces developers to be explicit about their intent, catching bugs during development while still allowing performance-critical release builds.

Preventing overflow requires proactive detection. Here are robust techniques for different operations.

Technique 1: Pre-operation checks

Check before the operation whether it would overflow:

// Safe signed addition: check before adding
bool safe_add_int(int a, int b, int *result) {
    if (b > 0 && a > INT_MAX - b) return false;  // Would overflow positive
    if (b < 0 && a < INT_MIN - b) return false;  // Would overflow negative
    *result = a + b;
    return true;
}

// Safe signed multiplication: check before multiplying  
bool safe_mult_int(int a, int b, int *result) {
    if (a > 0 && b > 0 && a > INT_MAX / b) return false;
    if (a > 0 && b < 0 && b < INT_MIN / a) return false;
    if (a < 0 && b > 0 && a < INT_MIN / b) return false;
    if (a < 0 && b < 0 && a < INT_MAX / b) return false;
    *result = a * b;
    return true;
}

Technique 2: Use wider types for intermediate calculations

Temporarily promote to a larger type, perform the calculation, then check if the result fits:

bool safe_add_int32(int32_t a, int32_t b, int32_t *result) {
    int64_t wide_result = (int64_t)a + (int64_t)b;
    if (wide_result > INT32_MAX || wide_result < INT32_MIN) {
        return false;  // Would overflow
    }
    *result = (int32_t)wide_result;
    return true;
}

This approach is cleaner and often faster than pre-checks, but doesn't work when you're already using the widest available type.

Technique 3: Compiler built-ins

Modern compilers provide overflow-checking intrinsics:

// GCC/Clang built-ins
int a = 1000000000, b = 2000000000, result;
if (__builtin_add_overflow(a, b, &result)) {
    printf("Overflow detected!
");
} else {
    printf("Sum: %d
", result);
}

// Similar for multiplication
if (__builtin_mul_overflow(a, b, &result)) {
    printf("Multiplication overflow!
");
}

These compile to efficient code that uses hardware overflow detection flags.

Let's examine real-world scenarios where overflow commonly occurs, even in experienced developers' code.