Fix sign extension in BitField.getValue for top-bit fields#1749
Merged
garydgregory merged 1 commit intoJul 17, 2026
Conversation
Member
|
Good find @alhudz , will merge, do you see other issues in the code base wit bit shifts? |
There was a problem hiding this comment.
Pull request overview
Fixes incorrect sign extension when extracting bitfields that occupy the top bit(s) of an int (bit 31) or long (bit 63) in BitField.getValue(...), ensuring extracted values reflect the intended unsigned magnitude.
Changes:
- Switch
BitField.getValue(int)to use unsigned right shift (>>>) to avoid sign extension for top-bit fields. - Switch
BitField.getValue(long)to use unsigned right shift (>>>) to avoid sign extension for top-bit fields. - Add targeted regression tests covering top-bit and top-range masks for both
intandlongholders.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/main/java/org/apache/commons/lang3/BitField.java | Uses unsigned right shift in getValue overloads to prevent sign extension when the masked value is negative. |
| src/test/java/org/apache/commons/lang3/BitFieldTest.java | Adds regression tests validating correct extraction for fields at bit 31 and bit 63 (and high-range masks). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+155
to
+156
| // The int and long overloads must agree for the same field and holder. | ||
| assertEquals(topByte.getValue(0xFF000000L), 255L); |
garydgregory
added a commit
that referenced
this pull request
Jul 17, 2026
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.
BitField.getValue(int)andgetValue(long)read the field withgetRawValueand then shift it down with an arithmetic>>. When the field sits on the top bit of the holder (bit 31 for theintoverload, bit 63 for thelongoverload added in 3.21.0) the masked value is negative, so>>sign-extends and the field reads back negative.new BitField(0x8000000000000000L).getValue(0x8000000000000000L)gives-1for a one-bit field whose value is1, andnew BitField(0xFF000000).getValue(0xFF000000)gives-1from theintoverload whilegetValue(long)returns255for the same field.Use the unsigned
>>>in both getters so the selected bits come down as magnitude. The value is reconstructed at the shift, so fixing it there also coversgetShortValue/getByteValue, which delegate throughgetValue, and it leaves the mask handling from #1711 untouched. Fields that do not reach the top bit are unchanged because>>and>>>agree on a non-negative value.