On Thu, 6 Nov 2025 21:03:01 GMT, Archie Cobbs <[email protected]> wrote:
>> When bit shifting an `int` or `long` value by an amount `X`, all but the
>> last 5 or 6 (respectively) bits of `X` are ignored.
>>
>> This can create a trap for the unwary, as in this example:
>>
>> public long readLongBigEndian(byte[] buf, int offset) {
>> return ((buf[offset + 0] & 0xff) << 56) // BUG HERE
>> | ((buf[offset + 1] & 0xff) << 48) // BUG HERE
>> | ((buf[offset + 2] & 0xff) << 40) // BUG HERE
>> | ((buf[offset + 3] & 0xff) << 32) // BUG HERE
>> | ((buf[offset + 4] & 0xff) << 24)
>> | ((buf[offset + 5] & 0xff) << 16)
>> | ((buf[offset + 6] & 0xff) << 8)
>> | ((buf[offset + 7] & 0xff);
>> }
>>
>> This PR adds a new warning when the compiler detects an out-of-range bit
>> shift, i.e., an `int` bit shift not in the range `[-31...31]` or a `long`
>> bit shift not in the range `[-63...63]`.
>
> Archie Cobbs has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Don't warn for negative shift values that are otherwise in range.
Looks good to me. I think I prefer this more conservative approach. Thanks!
FWIW, from a corpus run, there are 5 cases of shift `-1`, 2 cases of shift `-5`
and one cases of shift `-31`.
-------------
Marked as reviewed by jlahoda (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/27102#pullrequestreview-3447888795
PR Comment: https://git.openjdk.org/jdk/pull/27102#issuecomment-3516714885
