Integer Arithmetic Is Not Safe by Default: The Overflow Contract You Didn’t Define

​

The Unsafe Default You Use Every Day

We tend to treat integer arithmetic as “safe by default”. It isn’t.

Using +, -, or * on integers introduces a hidden weakness in your code. That risk becomes real whenever limits are not explicitly considered.

The issue is simple: these operations assume the result fits in the chosen integer type, but that assumption is often not validated.

In practice, this assumption is often left unchecked. When it fails, arithmetic becomes a silent source of bugs.

This is the same class of problem described in The Silicon Limit: Why Floating-Point and Integer Math Fails Silently, where numeric assumptions break without warning. Here, the problem is not precision—it is range.

​

Why Division Gets Attention (and the Rest Doesn’t)

Division is usually handled differently.

In mathematics, division by zero is forbidden, and in programming, it is widely recognized as an invalid operation. On top of that, integer division loses precision, which makes developers more cautious.

As a result, division is often guarded with checks.

But addition, subtraction, and multiplication do not raise the same concerns. In mathematics, they are always defined. There is no restriction that forces you to think about limits.

That intuition carries into programming, and this is where the mistake happens.

On a computer, integers are finite. Every operation is bounded by representation limits. When those limits are exceeded, the behavior is no longer purely mathematical.

So the focus of this article is not division. It is the operators we trust the most: +, -, and *.

​

The Missing Question

Every time an arithmetic operation happens, there is an implicit assumption.

What should happen if the result cannot be represented?

This question is often not answered explicitly in code or design. Instead, the behavior is inherited from the language, the compiler, or the hardware.

That is the root of the problem.

​

The Same Operation, Different Outcomes

Consider a simple addition that exceeds the maximum value of an integer.

Depending on the environment, several things can happen.

• The value may wrap around and continue from the minimum.
• It may saturate and stay at the maximum.
• It may trigger a panic or exception.
• It may even be treated as impossible by the compiler, leading to undefined behavior.

All of these behaviors exist in real systems. The problem is that the chosen behavior is often implicit.

​

Overflow Is a Design Choice

Every system that performs integer arithmetic implicitly defines a model for overflow and underflow. There are only a few meaningful models, and each has different consequences.

​

1. Wrap-Around (Modular Arithmetic)

One common model is wrap-around arithmetic, where values cycle within a fixed range. For example, adding one to the maximum value produces the minimum value.

 1package main
 2import "fmt"
 3func main() {
 4  // Create 8-bits unsigned integer starting at 255
 5	var number uint8 = 255
 6	fmt.Println("Start number:", number)
 7  // Try to add 1
 8	number = number + 1
 9	fmt.Println("After adding 1:", number)
10}

Start number: 255
After adding 1: 0

This behavior is natural for hardware and useful in domains like hashing, ring buffers, or sequence numbers. However, outside these cases, it introduces bugs that are hard to detect because the result still looks valid.

​

2. Saturation (Clamping)

Another model is saturation. In this case, instead of wrapping, values are clamped to a minimum or maximum. If a value exceeds the allowed range, it stays at the boundary.

1% Create a uint8 starting at 255
2number = uint8(255);
3disp(['Start number: ', num2str(number)])
4% Try to add 1
5number = number + 1;
6disp(['After adding 1: ', num2str(number)]) 

Start number: 255
After adding 1: 255

This is often used in image processing or signal processing, where exceeding a range should not invert or corrupt the meaning of the data. The downside is that information is lost silently, although in a controlled way.

​

3. Panic / Exception

A third model is to stop execution. In this case, the program panics, throws an exception, or crashes when overflow occurs.

This approach is common in safer environments or debug modes. It turns silent corruption into an explicit failure, which is often preferable in critical systems such as financial or safety-related applications.

​

4. Undefined Behavior

Another model is to assume that overflow never happens.

This is one of the most dangerous models (it contributed to failures such as the Ariane 5 rocket and Boeing 787 software bugs).

In languages like C and C++, signed integer overflow is undefined behavior. The compiler is allowed to assume it does not occur, which means it can remove checks or optimize code in ways that break logic when overflow actually happens.

For example, if you have x + 1 >= x, the compiler might optimize this to true because it assumes x + 1 will never overflow. If x is INT_MAX, x + 1 overflows, and the comparison becomes INT_MIN > INT_MAX, which is false.

​

5. Arbitrary Precision

Finally, some languages avoid overflow entirely by allowing integers to grow dynamically. In this model, values expand as needed to represent the result exactly.

This removes overflow as a failure mode but introduces trade-offs in performance and memory usage.

None of these models is universally correct. Each one is appropriate in specific contexts.

The problem is not choosing the wrong one. The problem is not choosing at all.

​

What About Subtraction and Multiplication?

The same issue applies beyond addition. Subtraction can underflow.

For example, subtracting a larger value from a smaller one in an unsigned type produces a large positive value instead of a negative result. This is often counterintuitive and leads to incorrect logic when values are assumed to stay within expected bounds.

Multiplication is even more dangerous because it grows values faster. It is easy to exceed limits without realizing it, especially when combining user input, scaling factors, or accumulated values. Unlike addition, where limits may be approached gradually, multiplication can cross them in a single step.

The underlying issue remains the same. The operation itself is valid in mathematics, but the representation is not guaranteed to hold the result.

​

A Note on Negation

Negation (-x) is often assumed to be safe because it is simple and unary, but it is effectively equivalent to 0 - x and follows the same rules as subtraction.

For signed integers, there is a critical edge case. The minimum representable value has no positive counterpart in two’s complement representation. Negating it produces a value that cannot be represented (overflows). On an 8-bit signed integer, the range is [-128, 127]. Negating -128 would require +128, which does not exist in that range.

If the system uses wrap-around arithmetic, the operation behaves as 0 - (-128) = 0 + 128 = 128, which overflows and wraps back to -128, producing the same value. In a saturating model, the result would instead be clamped to 127, the maximum representable value.

Both behaviors follow directly from how subtraction is defined under finite limits.

For unsigned integers, there is no special edge case like signed minimum values.

This means negation is not a special operation. It is another place where representation limits and the chosen arithmetic model determine the result.

​

A Note on Division

Division is usually treated more carefully, but it is not entirely safe either.

Division by zero is explicitly invalid and is typically handled by the language or runtime. However, there are still edge cases that are often overlooked.

Integer division truncates results, which may not match expectations.

There are also overflow scenarios, such as dividing the minimum signed integer by -1 in certain languages, which cannot be represented and lead to undefined or implementation-defined behavior.

So while division receives more attention, it is not exempt from the same class of issues.

​

Language Defaults Are Not Uniform

At this point, it should be clear that behavior depends heavily on the language.

Some languages define wrap-around behavior for both signed and unsigned integers (e.g.: Go, Java, C#).

Others distinguish between them, allowing wrap-around for unsigned values while treating signed overflow as undefined (e.g.: C, C++, Objective-C, Fortran).

Some languages saturate values instead of wrapping (e.g.: MATLAB/Octave).

Others avoid overflow entirely by using arbitrary precision integers (e.g.: Python).

Some languages detect overflow and stop execution in certain modes (e.g.: Rust, Zig, Swift).

Some even convert integers to floating-point numbers when overflow occurs (e.g.: PHP).

Others use floating-point numbers for all numeric operations (e.g.: JavaScript, Lua < 5.3).

There is no universal rule.

This means that moving code between languages, or even between build configurations of the same language, can change the behavior of arithmetic without changing the code itself.

That is a risk many systems do not account for.

Below is a practical summary of default behaviors (for +, -, and *).

​

Designing With an Explicit Model

The only reliable way to handle this is to make overflow behavior explicit.

Start by defining the valid range of values in your system. This includes not only the current values but also the results of all operations that can be performed on them.

Then define what should happen when that range is exceeded. Should the value wrap around? Should it be clamped? Should the program stop? Or should the operation be prevented entirely?

Once that decision is made, enforce it consistently.

This can be done through language features such as checked arithmetic operations, through explicit validation before performing operations, or by using types and abstractions that encode constraints directly into the system.

What matters is that the behavior is defined and applied consistently.

​

Practical Takeaways

Integer arithmetic is not inherently safe. It only appears safe because failures are often silent.

Overflow and underflow are not edge cases. They are normal outcomes of operating on finite representations.

The real issue is not that these behaviors exist, but that they are often implicit and inconsistent across a system.

If you rely on integer arithmetic, you need to decide how your system handles these cases. If you do not, that decision will be made for you—by the language, the compiler, and the hardware—and it may not match your expectations.