fix: try_get_int/try_get_int_le do not sign-extend n-byte integers#839
Open
teddytennant wants to merge 1 commit into
Open
fix: try_get_int/try_get_int_le do not sign-extend n-byte integers#839teddytennant wants to merge 1 commit into
teddytennant wants to merge 1 commit into
Conversation
`Buf::try_get_int` and `Buf::try_get_int_le` read the requested bytes into the low bytes of a zeroed `[u8; 8]`, so for `nbytes < 8` the high bytes stayed zero and no sign extension happened. A negative value such as the 3-byte `0xffffff` was returned as `16777215` instead of `-1`, unlike the panicking `get_int`/`get_int_le` which sign-extend via `sign_extend`. Make the fallible getters mirror their panicking counterparts by sign-extending the result of `try_get_uint`/`try_get_uint_le`. `try_get_int_ne` delegates to these and is fixed transitively. Error and panic behavior is unchanged.
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.
What
Buf::try_get_intandBuf::try_get_int_lenow sign-extend the value they read fornbytes < 8, matching the behavior of the panickingBuf::get_int/Buf::get_int_le.Why
The panicking getters sign-extend via
sign_extend(self.get_uint(nbytes), nbytes). Their fallible twins instead usedbuf_try_get_impl!, which copies the bytes into the low bytes of a zeroed[0u8; 8]and callsi64::from_{be,le}_bytes. Fornbytes < 8the high bytes stay zero, so no sign extension happens and a negative value is returned as a wrong positive number.For example, the 3-byte big-endian value
0xffffff(whichget_int(3)returns as-1) was returned bytry_get_int(3)as16777215.try_get_int_nedelegates to these two methods and inherited the bug; it is fixed transitively. NoBufimplementation overrides these methods, so all implementors were affected.The fix makes the fallible getters mirror their panicking counterparts:
Edge cases are preserved:
nbytes > 8still panics viatry_get_uint's documented check,nbytes == 8is an identity shift, and insufficient data still returns the sameErr(TryGetError { requested, available })as before (existing doctests unchanged).Testing
try_get_int_sign_extendstotests/test_buf.rs, covering big/little/native-endian sign extension, a positive value, full width, and the insufficient-data error shape. It fails onmaster(try_get_int(3)returnsOk(16777215)) and passes with this change.cargo testpasses all suites and doctests, including the existingtry_get_int/try_get_int_ledoctests.cargo fmt --all --checkis clean.