byte_pos.saturating_mul(100) does not merely lose precision at the top
of the range --- it collapses the numerator to a constant. u64::MAX
times 100 saturates to u64::MAX, and u64::MAX / u64::MAX is 1, so a
cursor at the very end of a maximal buffer read 1%.
Wrong in the worst way available: in range, plausible, and passing
every test. percent_is_always_in_range asserted only p <= 100, which
Percent(1) satisfies perfectly. The sweep even included the exact
(u64::MAX, u64::MAX) pair and reported success, because it never asked
what the answer should be.
Computes in u128 now. u64::MAX * 100 fits with room to spare, so the
product is exact and the only remaining clamp is the genuine one --- a
caller reporting a cursor past the end still gets 100%, never above.
large_byte_counts_stay_accurate is the correctness witness the range
sweep could not be. It bites: against the old arithmetic it fails with
left: Percent(1)
right: Percent(100)
while percent_is_always_in_range keeps passing, which is the point of
adding it rather than extending that one. It also pins u64::MAX/2 at
49% and u64::MAX/4 at 24%, and includes u64::MAX/100 + 1 --- the
smallest position whose scaling overflows u64, and therefore the first
input the old code got wrong.
percent_is_always_in_range keeps its sweep and gains a note about what
it does not prove, so the next reader does not mistake bounded for
correct.
Gates: fmt, workspace clippy -D warnings, diff --check,
pmacs-protocol --lib 25/0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Levi Neuwirth
b8639130d9