Why does a 32-bit signed revenue total silently go negative instead of raising an error?

## What "fixed-width" actually buys and costs A fixed-width integer type reserves a constant number of bits — 8, 16, 32, 64 — and can therefore represent only a finite set of values. A 32-bit signed type covers about -2,147,483,648 to +2,147,483,647; a 64-bit signed type covers roughly ±9.22 × 10^18. The benefit is that every value costs the same known amount of memory and every operation is a single machine instruction. The cost is that the arithmetic is not the arithmetic of the whole numbers: it is arithmetic **modulo 2^width**, with the upper half of the wheel reinterpreted as negative values. Adding 1 to the largest representable value cannot produce "largest plus one" — no such value exists in the type — so it produces the most negative one. There is no edge to fall off; the wheel simply comes round. ## Why nothing complains Processors do set an overflow flag when a signed result did not fit. Almost no generated code looks at it. Testing that flag after every arithmetic operation would put a branch on the hottest instruction in the machine, so the default operators omit the check and expose it only through explicit checked-arithmetic operations that a programmer opts into. Language definitions then diverge on what the silent result *means*: Java and Go define the result as the wrapped value, while C and C++ declare signed overflow undefined so that optimizers may assume it never occurs. From the caller's point of view the difference is invisible in the moment — no exception, no fault, no log line. The only evidence is a number that is wrong. ## The rollup, concretely Money is normally accumulated in minor units (cents) so that no fractional arithmetic is involved. That choice multiplies the magnitude by 100 and therefore divides the headroom by 100. A 32-bit signed accumulator of cents overflows at about 21.5 million currency units. A single shop never approaches that. A marketplace on a peak day, a rollup widened from one day to one month, or a backfill that re-runs and double-counts, all do. The characteristic trace is: the total climbs normally for hours, then in one increment becomes a large negative number, and the crossing point moves with traffic rather than with a code change. That is why it survives every test suite — test fixtures have five orders in them — and appears first in production. ## The wrong answers this question is aimed at - **"Overflow throws something I can catch."** Only if you asked for checked arithmetic. The default is silence. - **"It stops at the maximum."** Clamping at the extreme is *saturating* arithmetic, a deliberate policy some numeric libraries offer. It is not what plain fixed-width operators do. - **"Precision was lost, like with decimals."** Nothing was rounded. Integer wraparound is exact modular arithmetic; the value is wrong by exactly 2^32, not approximate. - **"Storing the sum in a wider column fixes it."** The damage happens where the arithmetic is performed. Widening the destination after the fact preserves the already-wrapped value. - **"Use an unsigned counter, it cannot go negative."** True and useless: an unsigned 32-bit accumulator merely doubles the headroom and then wraps to a small positive number, which is *harder* to notice than a negative total because it still looks plausible. ## What to do instead 1. **Size the accumulator for the whole domain, not the sample.** A 64-bit total of cents holds roughly 9.2 × 10^16 currency units. No commerce workload reaches it, so the class of bug disappears rather than being managed. 2. **Widen at the point of arithmetic.** The width of the *operands* decides where the sum is formed; the width of the variable you assign into does not rescue a computation that already wrapped. 3. **Use checked arithmetic where a wrong number is worse than a failed request.** Money, quotas and sizes qualify. Checked addition signals on overflow rather than returning a wrapped value, converting a silent corruption into a loud failure you can page on. 4. **Assert the invariant.** A running total of non-negative amounts is monotonically non-decreasing. One cheap comparison per batch turns an invisible wrap into a caught bug, and it also catches unrelated defects like a sign error in refund handling. 5. **Test at volume, not at scale one.** A property test that feeds a synthetic multiple of peak volume through the rollup crosses ceilings that hand-written fixtures never approach. ## The mental model to keep A fixed-width integer is a clock face, not a number line. Every operation is exact and every operation is modular. The engineering question is never "could this value be big?" in the abstract — it is "what is the largest value this expression can produce, in the width where it is computed, over the worst input this system will ever see?" Answer that once per accumulator and the whole family of bugs goes away.