Why can a backwards array scan using an unsigned index never terminate when its loop guard is `i >= 0`?

## The tautological guard An unsigned n-bit integer represents 0 .. 2^n - 1 and nothing else. A guard of the form `i >= 0` over such a type compares against the bottom of the representable range, so it is true for every value the variable can hold — the compiler could replace it with `true` without changing behavior (and some toolchains warn precisely because of that). The loop's only exit path is gone before the first iteration runs. ## Where the values actually go ``` i = length(samples) - 1 // i is a 32-bit unsigned integer while i >= 0: checksum = checksum XOR samples[i] i = i - 1 ``` The scan is perfectly correct from n-1 down to 0. The failure is the *final* decrement: unsigned arithmetic is defined modulo 2^n, so `0 - 1` yields 2^32 - 1 = 4,294,967,295. That is the all-ones bit pattern — the very pattern that reads as **-1** in two's complement. Nothing overflowed in the hardware's eyes; the subtraction did exactly what modular arithmetic promises. The next iteration indexes `samples[4294967295]`, and the loop never ends on its own. Note the second landmine in the first line: for an **empty array**, `length - 1` performs the same wrap before the loop even starts, so the guard-restructuring fix must handle n = 0, not just the countdown. ## The same pattern, the comparison version The deeper representational fact — signed -1 and unsigned maximum share one bit pattern — also corrupts comparisons between a signed counter and an unsigned length field. In languages that implicitly convert mixed operands, the signed side is converted to unsigned, so: ``` i = -1 // signed sentinel: "not found" if i < length(buffer): // length is unsigned ... // -1 converts to 4294967295: comparison is false ``` The branch silently evaluates as `4294967295 < length` — almost always false — and the sentinel sails through logic that visibly checks for it. Ecosystems split three ways on this exact point: C and C++ perform the implicit conversion (the classic source of the bug), Go and Rust reject mixed signed/unsigned comparisons at compile time, and Java sidesteps the category by offering no unsigned primitive types at all. The disagreement is a signal that the trap is real enough to design a type system around. ## Recognizing it in production Symptoms that should trigger this hypothesis: - A loop that "cannot exit" whose guard reads as obviously sensible. - A crash or bounds fault at an index near 4 billion (or 65535, or 2^64 - 1 — the width names the culprit). - A `>= 0` or `< length` check that a debugger shows evaluating the "wrong" way with a -1 in play. The near-2^n magnitude is the fingerprint: it says a small negative quantity was read through an unsigned lens. ## Fixes, ranked by robustness 1. **Use a signed index** wide enough for every legal index (a 64-bit signed type covers any 32-bit length). The guard then means what it says. 2. **Restructure the countdown**: `while i > 0`, operate on `a[i - 1]`, decrement — every value of `i` stays in 0..n and zero is the natural exit. Handles the empty array for free. 3. **Count remaining elements** instead of positions: `remaining = n; while remaining > 0: process(a[remaining - 1]); remaining = remaining - 1`. 4. Casting inside the guard is the weakest fix — it patches one comparison, leaves the wrap on decrement in place, and still misses n = 0. In review, the senior-level habit is to treat any arithmetic that can cross zero on an unsigned type — countdowns, `length - 1`, size differences like `a - b` — as suspect by construction, and to keep index types signed or comparisons homogeneous at API boundaries.