Repository navigation
policy: json_int53.t27 -- a 64-bit integer does not travel as a bare JSON number (Closes #10437) - #10438
Merged
Conversation
…JSON number; negative control, scanner, measured list (Closes #10437) A JS reader rounds every JSON integer above 2^53 - 1: 9007199254740993 reads as 9007199254740992. The spec states the rule (string, or a 53-bit proof), carries the negative control and a digit-text scanner (16 tests, 0 vacuous on the lab). The measured report lists 35 (file, field) pairs in 32 JSON files and 121 gen-js literals from 53 specs; writers are follow-ups (Python generators to .t27, gen-js BigInt needing owner-approved-foreign). Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
This was referenced Oct 18, 2026
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #10437
A JavaScript reader turns every JSON number into an f64, so an integer above 2^53 - 1 comes back rounded and nothing throws. Idea taken from morluto/rea 6.6.0, which fixed the same defect three times.
What lands
specs/policy/json_int53.t27(modulePolicyJsonInt53): the rule (a 64-bit or wider integer is a decimal or 0x-hex string, or carries a proof of at most 2^53 - 1), the negative control (9007199254740993 reads as 9007199254740992; NaN payload 0x7FF8000000000001 reads as 0x7FF8000000000000), and a scanner that finds bare integers above 2^53 - 1 in a JSON buffer by comparing digits as text, so it uses no rounding number type.gen/c/policy/json_int53.cand.trinity/seals/policy_PolicyJsonInt53.json, produced by gen-c and seal on the Railway lab.docs/reports/2026-10-18-json-int53-measured.md: the measured list.Measured
conformance/vectors/*.jsonfiles (one field,gf256 bits, holds 2018 of them) plus the deliberate 2^53 boundary id inconformance/tmem_bridge.json.export constlines that gen-js prints as bare number literals above 2^53 - 1, from 53 specs, includingSUPPLY_NGONKA = 446378386939836973.Not fixed here
No writer can be fixed without foreign code: the vector generators are hand-written Python, and gen-js / gen-ts are Rust. Follow-ups are listed in the issue: port the generators to
.t27emitting string spellings; make gen-js / gen-ts print BigInt or string for constants above 2^53 - 1 (needsowner-approved-foreign); a CI gate that runs the scanner over tracked JSON.Verification
test-report on the Railway lab: 16 of 16 pass, 0 vacuous passes, every test's runtime assert count above 0. Scanner test lengths come from
.len, not hand counts.🤖 Generated with Claude Code