You are setting the arithmetic policy for a codebase that does size, quota and money calculations on untrusted numbers across several languages. How do you decide between checked (fail-fast), saturating, wrapping and wider-type arithmetic, and where do you put the guarantee?

## Start from the sink, not the operator The policy question is not "which arithmetic is safest" but "what does this number decide". Group the codebase's arithmetic into three bands: - **Authority-bearing**: allocation sizes, bounds and offsets, money and fees, quotas and balances, entitlement counts, expiry and validity windows, retry and lockout counters. - **Structural**: indices, capacities and internal bookkeeping that is derived from already-validated values. - **Cosmetic**: metrics, progress, display, telemetry. Only the first band justifies a hard policy. Applying one everywhere burns credibility and produces a wall of noise that teams learn to bypass. ## The four modes and what each buys **Checked / trapping.** The operation either yields the mathematically correct value or signals failure — an error return, an exception, a panic. This is the **structural separation** rung of the defence ladder: the wrong value is unrepresentable downstream. The cost is that every call site must handle a failure path, which is precisely the design pressure you want on authority-bearing arithmetic, because it forces the author to decide what "this request is absurd" means. Reject at the boundary with a clear error; do not clamp and continue. **Saturating.** Clamps at the type's limits. It sits on the **transformation** rung, and the reason it is strictly below checked arithmetic is worth stating: saturation still produces a *wrong* value — it merely makes the wrongness monotonic instead of discontinuous. That is exactly right for a back-off delay or a rendered bar, where "as much as possible" is the intended meaning. It is exactly wrong for an allocation size, where the clamp turns a wrap into a maximal allocation and a memory-exhaustion denial of service, and for money, where clamping silently changes the amount a customer owes. **Wrapping.** Correct and necessary for hashes, checksums, PRNGs, ring-buffer indices and sequence numbers that are defined modulo something. The policy is not to forbid it but to require it be *named* — a wrapping-add function or an explicitly documented type — so that a reader can distinguish deliberate modular arithmetic from an accident. Silent wrap as the language default is the problem; wrap as a stated intent is fine. **Wider types.** Widening is a *range argument*: it is valid only when you can state and defend the bound on the entire expression, including every future term. It is a legitimate technique — compute in a type that provably holds the product of the validated operand ranges, then validate the result once and narrow — but it is not a control, because nothing enforces the bound after the next edit. It also introduces its own boundaries: a 64-bit identifier or amount that crosses a JSON or JavaScript hop becomes a double and loses exactness above 2^53, so two distinct identifiers can compare equal with no wrap and no error. Cross-language numeric boundaries deserve the same scrutiny as the arithmetic itself; where they exist, carry large integers as strings. ## Where the guarantee lives A policy that lives in a wiki is a detection control at best. Push it into the code: - **Types**: money as a decimal or minor-unit type with checked operations rather than a raw integer; sizes as a dedicated type that only supports checked operations. - **Helpers**: one `checked_add` / `checked_mul` / `range_within` per codebase, so the correctness proof exists once and every call site inherits it. - **Build settings** where the language offers them: overflow checks enabled in the modes you actually ship, or a documented decision that they are not, with the reasoning recorded. Note that defining wraparound (rather than leaving it undefined) removes the compiler-deletes-your-check hazard but keeps the wrong value — it is a correctness improvement, not a defence. - **Detection, last**: overflow sanitizers in CI, fuzzing the parsers that consume declared lengths, property tests asserting that computed sizes match what is actually written. This is the bottom rung — it finds instances and guarantees nothing, so it must never be the primary control. ## The polyglot problem Different runtimes give the same source construct different meanings: defined wraparound, undefined behaviour, debug-only panics, arbitrary precision that fails as memory exhaustion instead, and floating-point that rounds rather than wraps. A single global rule cannot hold. Write the policy in terms of *guarantees required at the sink* — "a size that reaches an allocator must have been produced by an operation that cannot silently return a wrong value" — and let each language satisfy it with its own mechanism. Then the review question is uniform even though the implementations differ. ## What good looks like A reviewer opening a diff should be able to see, from the shape of the code alone, that an authority-bearing quantity was computed safely, and a raw operator on untrusted input in that band should look conspicuous. If deciding requires re-deriving the algebra, the policy has failed regardless of how correct the individual expressions currently are.