Float and integer arithmetic follow two different paradigms

The write-up argues that integer and floating-point arithmetic demand fundamentally different safety paradigms. Integer overflow must be anticipated because compilers assume well-formed code and will optimize away post-failure checks, leading to undefined behavior or security bugs. Languages and toolchains enforce this by providing explicit checked/wrapping/saturating/overflowing operations (Rust’s checked_* variants) or compiler intrinsics and newer C helpers (builtin overflow checks, C23’s ckd_ functions). Developers therefore need to structure code to avoid or explicitly handle integer failure conditions up front rather than detect them after the fact.

Floating-point arithmetic, by contrast, produces IEEE-754 NaN and infinity values that safely propagate through computations, so a better pattern is to perform calculations and validate results (e.g., isfinite) once rather than littering code with zero or tiny-epsilon guards. This reduces rejected inputs and unnecessary checks and handles many complex fault cases (like 0/0 or negative roots) by letting NaNs travel to a single final check. Caveats include numerical instability - finite results can still be meaningless due to precision loss - and environments like GLSL that don’t reliably emit NaN or provide isfinite, which break this approach. The practical takeaway: stop treating floats like integers and prefer end-of-pipeline validation over pervasive defensive checks.