Repository navigation
Fix repeated rounding when decoding large integers - #16
Open
bensynapse wants to merge 1 commit into
Open
bensynapse wants to merge 1 commit into
bensynapse wants to merge 1 commit into
Conversation
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.
I run Live Tennis API.
The integer path currently accumulates each digit in float64. Larger values can round several times before decoding finishes.
For the ID in #13, the CLI emits 144126219108390080. With this fix, it emits 144126219108390100, matching encoding/json.
Once the magnitude reaches 2^53, reuse the existing strconv.ParseFloat path. Smaller integers keep their existing arithmetic path.
Oversized integers now return the same range error as oversized decimal and exponent values.
This corrects extra rounding. The public values remain float64, so integers beyond its precision still cannot retain every digit.
Related to #13.
The workflow's go test -v -race ./... passes on Go 1.13.15, 1.14.15 and 1.23.4.
Its configured golangci-lint v1.21.0 check passes. Builds and go vet also pass.
The new tests cover both signs, the 2^53 boundary, negative zero and overflow. Ten rounding cases and both overflow cases fail before the fix.
The built CLI passes eighteen checks for JSONL and key value output, signed zero and overflow.