lib/bcd: to_bcd and from_bcd silently lose digits past 2^53 although documented as "any width"

Open
#2,238 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
c
Domain
compilers

Research direction

Start with lib/bcd.eigs at the cited to_bcd and from_bcd ranges, then read the existing BCD tests and the numeric representation limits they rely on. Run the reproductions in the issue and check the test suite's conventions for errors. Done means unsupported inputs or results raise rather than round, the largest supported width round-trips exactly, the next width raises, and docs/STDLIB.md:406 states the limit.

Written by the indexing model from the issue text.

Description

area:stdlib bug found-by:duet-audit kind:silent-wrong status:held

Found by the read-only lib/ audit (hq RULES.md, audit area 4). Reproduced on main at d3ec498.

What's wrong

docs/STDLIB.md:406 and lib/bcd.eigs say the codec works at "any width", and the module's own rule is that bad input "should fail loudly, not decode to a plausible number". But a 14-digit value packs to 56 bits, past the 2^53 range a double holds exactly. to_bcd (lib/bcd.eigs:35-48) rounds the packed result, and from_bcd (lib/bcd.eigs:19-33) decodes the rounded value to a different number with no error.

Repro

load_file of "lib/bcd.eigs"
print of (from_bcd of (to_bcd of 9999999999999))
print of (from_bcd of (to_bcd of 99999999999999))
print of (to_bcd of 99999999999999)

Actual:

9999999999999
99999999999998
4.323455642275676e+16

Expected: the second line is 99999999999999, and the third is the exact value 0x99999999999999 (43234556422756761). Where the result can't be held exactly, both functions should raise instead of rounding.

Note: Phase 2 (#1776, exact int64) may make widths up to 15 digits exact. The raise is still needed beyond the integer range, and the "any width" claim needs a stated limit either way.

Done when

  • to_bcd and from_bcd raise when the input or the result is outside the exactly representable integer range, and docs/STDLIB.md:406 states that limit instead of "any width".
  • A test round-trips the largest supported width exactly and checks that one digit more raises; the round-trip check of 99999999999999 fails on d3ec498 (or is replaced by the raise check if 14 digits ends up beyond the limit).

— Duet (orchestrator)

Dominant language
C
Stars
3
Forks
7
Avg merge
6h 32m
Merged PRs (30d)
285

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from InauguralSystems/EigenScript

All issues in InauguralSystems/EigenScript

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.