Visual walkthrough — Undefined Behavior Sanitizer (UBSan)

---

Step 1 — What "the biggest number" even means

WHAT. A signed 32-bit int is a row of 32 boxes, each holding a $0$ or a $1$. We call one box a bit. Thirty-two boxes give us a fixed, finite set of numbers — no more, no less.

WHY. Overflow is only possible because the set is finite. If we understand the boundary of that set, we understand exactly when we fall off it. So before anything else we must draw the whole number line these 32 boxes can reach.

PICTURE. Below, the number line is a ruler. The far-left tick is the smallest reachable value, the far-right tick the largest. Everything past the ends is "unreachable" (amber shaded).

We derive why these are the exact edges in Step 2. This bounded ruler is the whole reason overflow exists.

---

Step 2 — Why the edges sit at $-2^{31}$ and $2^{31}-1$

WHAT. We assign a weight to each of the 32 boxes and add up the weights of the boxes holding a $1$. That total is the number. This weighting scheme is two's complement.

WHY. We need to know the two edge values precisely, because our overflow test will be "did we leave $[-2^{31},2^{31}-1]$?". Those edges are not arbitrary — they fall straight out of the weights.

PICTURE. Each box gets a label. The rightmost box is worth $2^0=1$, then $2^1,2^2,\dots$ up to the second-from-left worth $2^{30}$. The leftmost box is special: its weight is negative, $-2^{31}$. That one negative weight is the whole trick of signed numbers.

---

Step 3 — What goes wrong: falling off the right edge

WHAT. Take $a=\text{INT\_MAX}=2^{31}-1$ and add $b=1$. The true answer is $2^{31}$. But $2^{31}$ has no box pattern — it is one tick past the right end of our ruler.

WHY. This is the exact moment of UB. We want to see, visually, what the boxes do when forced past the edge, so we can invent a test that spots it.

PICTURE. Watch the arrow leap off the right end and reappear at the far left. The result wraps to $-2^{31}$: all the low boxes carry, the carry ripples into the top box, and the top box flips from $0$ to $1$. A number that was positive suddenly reads as the most negative value.

---

Step 4 — The clue: the sign bit flipped

WHAT. In Step 3, both inputs were non-negative (top bit $0$) yet the result came out negative (top bit $1$). That mismatch is the fingerprint of overflow.

WHY. We want a cheap test — no big-number math. The picture in Step 3 hands us one: compare three sign bits. That is a single-bit comparison, which the CPU does for free.

PICTURE. Three little sign-bit tiles: $a$'s top bit, $b$'s top bit, and the result's top bit. When $a$ and $b$ agree but the result disagrees, we light the amber ALARM.

---

Step 5 — Why opposite signs can NEVER overflow

WHAT. Cover the case Step 4 quietly excluded: $a$ and $b$ have different signs (one positive, one negative).

WHY. A test must handle every case. We claim opposite-sign adds are always safe. If that's true, our first bracket ("same sign") is exactly right — no false alarms, no missed bugs.

PICTURE. One positive arrow points right, one negative arrow points left. Their sum lands between them — closer to zero than the longer arrow. It cannot reach past either input, so it cannot pass an edge that the inputs already sit inside.

---

Step 6 — The mirror case: falling off the LEFT edge

WHAT. Now $a=\text{INT\_MIN}=-2^{31}$ and $b=-1$. True sum $=-2^{31}-1$, one tick past the left end.

WHY. Symmetry check. We saw the right edge in Step 3; we must confirm the same sign-bit test catches the left edge too, otherwise we'd only catch half the bugs.

PICTURE. The arrow leaps off the left end and reappears on the right at INT_MAX. Both inputs were negative (top bit $1$), the result is positive (top bit $0$) — the mismatch fires again. Same alarm, other direction.

Recall Which sign pattern fires the alarm?

Same-sign inputs whose result flips sign ::: overflow. Opposite-sign inputs ::: always safe, never overflow.

---

Step 7 — Where the check actually lives: one CPU flag

WHAT. Real hardware doesn't compare bits with software ifs. The processor's adder sets an Overflow Flag (OF) that is exactly the Step 4 comparison, computed inside the add instruction.

WHY. This is why UBSan is cheap. It doesn't redo the math in wider integers — it just reads OF after the ordinary add and, if set, calls the reporter. That is why UBSan's slowdown is small (~1.2–2×), unlike ASan which reroutes all memory.

PICTURE. A flowchart: add a,b → read OF → if OF=0 keep going, if OF=1 jump to __ubsan_handle_add_overflow(loc,a,b) which prints file:line. The whole insertion is one branch.

---

The one-picture summary

The whole derivation on one ruler: opposite-sign adds stay safely inside (green), same-sign adds can leap off either edge and flip the sign bit (amber), and that single flipped bit — read as the OF flag — is the whistle UBSan blows.

Recall Feynman: the walkthrough in plain words

A 32-bit int is a ruler with a smallest and a biggest number and nothing beyond. The far-left mark of every number tells you its sign. When you add two numbers pointing the same way (both positive or both negative), you might shoot off one end of the ruler — and when you do, you reappear at the other end, so a number that was positive suddenly reads negative (or the reverse). That flipped sign is the tell. Adding numbers that point opposite ways can never do this, because you always drift toward the middle. So the referee's rule is dead simple: "if the two numbers had the same sign but the answer's sign is different, blow the whistle." The chip already computes exactly this as its Overflow Flag, so UBSan just peeks at that flag after each add — cheap, instant, and it points at the exact line.

---

Related: Compiler Optimization Levels · GCC and Clang Toolchains · Debugging with -g and Debug Info · Static Analysis vs Dynamic Analysis