Why can a digit-stripping recursion with an n == 0 base case never terminate on negative input?

## The claim being made, spelled out A digit-by-digit reduction — peeling one decimal digit per call off a signed account number to accumulate a checksum, say — carries an implicit termination argument: *the magnitude of `n` strictly decreases on every call and eventually equals zero, where the base case fires*. That argument has three parts, and the negative case attacks the first two. ## Rounding decides whether the measure decreases Integer division of a negative operand is defined two different ways, and both are in wide production use. - **Truncation toward zero**: -2517 becomes -251, then -25, then -2, then 0. The magnitude strictly decreases and hits the base. The recursion terminates. - **Rounding toward negative infinity (floor)**: -2517 becomes -252, then -26, then -3, then **-1**, and -1 divided by ten floors to -1 again. The value is a fixed point. The magnitude has stopped decreasing, so there is no longer a decreasing measure at all, and the `n == 0` equality is never satisfied. The lesson generalises past this one bug: *a termination argument is only as strong as the arithmetic it assumes*. The code says `n / 10` and the reviewer reads "gets smaller", but "gets smaller" is a property of the operation's rounding rule, not of the syntax. This is one of the few places where two mainstream language families genuinely disagree — Python floors, while C, Java and Go truncate toward zero — so the same recursion is correct in one and a hang in the other. The same rounding rule also corrupts the digits, which is worth noticing because it means the bug is not confined to termination. Under floor semantics the remainder is non-negative: -25 decomposes as 10 × (-3) + 5, so the digit extracted is 5 where the intended digit was 2. Termination is the loud symptom; the wrong checksum would have been the quiet one. ## Why negating on entry is a trap The reflex fix is to normalise the sign — take the magnitude once at the entry point, then recurse over a non-negative value. On fixed-width two's-complement integers this is unsafe, because the representable range is asymmetric: there is exactly one more negative value than positive, so the most-negative value has no positive counterpart. Negating it overflows — it either wraps back to itself, silently reproducing the original problem, or is outright undefined depending on the environment. A normalisation step that fails on precisely the extreme input you were trying to protect is worse than no normalisation, because it looks like due diligence. Safe alternatives: widen to a larger type before negating; or do not negate at all — recurse on the negative side, extracting digits by magnitude, and apply the sign once to the assembled result. ## Base on a region, not a point All of this argues for the same structural fix that fixes stride bugs: make the base case a **region** the step cannot jump over or stall inside. Stopping when the magnitude is below ten terminates from either sign under either rounding rule, because that condition is true of a whole neighbourhood rather than a single point. Equality bases are fragile precisely when the step's behaviour near the boundary is not fully pinned down — a stride bigger than one, a rounding rule you did not specify, a floating quantity that never lands exactly. ## What a senior answer adds The reason this question sorts candidates is that the mechanical answer ("negatives don't reach zero") is only the surface. What an interviewer is listening for: 1. **The measure is named** — magnitude toward zero — rather than implied. 2. **The assumption is surfaced** — the measure decreases only under one of two legitimate rounding rules, which the code does not document. 3. **The fixed point is identified** — -1 maps to itself, which is a stronger statement than "it goes negative". 4. **The obvious fix is examined and rejected** — asymmetric range, negation overflow at the extreme. 5. **The test set follows** — zero, single digits of each sign, and both representable extremes, because this whole family of defect lives at values that random and mid-range testing never generate. That last point is the practical payoff. Extremes and degenerate values are a small, finite, cheap set to enumerate, and they catch base-case coverage bugs, sign bugs and overflow bugs in the same pass.