Repository navigation
fix(types): reject integers that wrap around in parseUInt64 - #8678
Merged
Merged
Conversation
parseUInt64 detected an overflow only when the new value was smaller than the value before the last digit. A wrapped value can still be larger: 23058430092136939520 (2^61 * 10) wraps around to 2^62 and was accepted, so the JSON and XML decoders returned 2^62 for it (and -2^62 for its negative form through parseInt64). The hex branch had the same problem when the shift dropped a set bit, e.g. for 0x18000000000000000. Check before the multiplication and the shift whether the result still fits.
|
|
Member
|
Dividing by 10 in every iteration can be very expensive. Check if it can be implemented more efficient - or if compilers optimize sufficiently. |
Contributor
Author
|
Good point. It now compares against |
Member
|
Thanks, merged. |
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
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.
parseUInt64()only reported an overflow when the new value was smaller than the one before the last digit. That misses wraps that land higher:23058430092136939520(2^61 * 10) wraps to 2^62, which is larger than 2^61, so it was accepted. The JSON and XML decoders then returned 4611686018427387904 for a UInt64 with that value, and -4611686018427387904 for an Int64 of-23058430092136939520. The hex branch has the same gap when the shift drops a set bit, e.g.0x18000000000000000becomes 0x8000000000000000.This checks before the multiplication and the shift whether the result still fits, and drops the
prevcomparison. Only 64-bit values are affected; any missed wrap lands above 2^64/9, so 32-bit range checks downstream already rejected them.Tests: new decimal, hex and signed cases in
check_parse_num.c, and two JSON decode cases incheck_types_builtin_json.c.