A chunking recursion consumes two characters per call and bases only on n == 0 — which inputs never terminate?

## What the counter actually visits The recursion moves `n` to `n - 2` and stops only when `n` is exactly `0`. Subtraction by two preserves parity, so a call chain visits one parity class and only that one. From `n = 6` the chain is 6, 4, 2, 0 — the base matches and the recursion unwinds. From `n = 5` it is 5, 3, 1, -1, -3, -5, … The equality `n == 0` is false at every one of those values, forever. Nothing about the *measure* was wrong: it strictly decreased on every call, exactly as a termination argument requires. The base condition was simply never on the path the measure travels. This is the concrete answer to the belief that one base case is always enough. One base case is enough when the step size is one, because then the measure visits every intermediate value and cannot miss a single point. The moment the step is larger than one — subtract two, halve and subtract, drop a fixed-size header, skip a delimiter pair — the measure jumps over values, and a point-shaped base condition can be jumped over with it. ## The second bug hiding at n == 1 At `n == 1` the fragment computes `doc[n-2]`, which is `doc[-1]`: a read one position before the start of the document. Depending on how the underlying data is represented this either fails loudly or quietly returns something meaningless, and it happens *before* the recursive call, so a guard placed only on the recursive step would not prevent it. Two distinct defects therefore live at the same untested input, which is a good argument for the habit of writing the degenerate cases as tests rather than reasoning about them once. ## Fixing it properly The fix is to make the base cover every value the stride can land on: ``` if n <= 0: return "" if n == 1: return doc[0] + "|" ``` Two things are worth noticing. First, the guard on the runaway side is an inequality, not an equality: `n <= 0` catches any accidental undershoot instead of relying on the counter landing exactly on the point. Second, `n == 1` is a genuine *semantic* base case, not defensive padding — a one-character document has a correct answer, and someone has to produce it. Changing `n == 0` to `n <= 0` alone converts an infinite recursion into a wrong result plus the out-of-range read: the leftover character is silently dropped. Fixing termination without fixing the answer is a common half-fix. ## Generalising the rule For a recursion whose step subtracts `k`, the base must cover the whole remainder range `0 .. k-1`, because that is what the counter can land on when the input size is not a multiple of `k`. The same shape appears well beyond arithmetic strides: - Consuming a fixed-size record per call: the trailing partial record is the missed base case. - Splitting into two halves: sizes 0 and 1 are both degenerate and both need answers. - Peeling matched delimiters from both ends: zero and one remaining are distinct cases. ## The test set that catches it Random mid-sized inputs are almost useless here, because half of them terminate and the other half look like a hang rather than a wrong answer. The inputs that find base-case coverage bugs are always the small and degenerate ones: empty, one element, two elements, and the smallest input above the stride in each residue class. Writing those four as tests costs less than reasoning about parity in a review, and it catches the whole family — missing base case, off-by-one boundary read, and silently dropped remainder — in one pass.