On Thu, 12 May 2022 08:56:26 GMT, Daniel Fuchs <dfu...@openjdk.org> wrote:
>> No because the int returned could be negative, while the long will not.
>> Assuming bufferLen is 0 and codeLengthOf() returns some value that has the
>> 32th bit set to 1 then when codeLengthOf() returns long, bufferLen +
>> codeLengthOf() will be a positive long > 64, and we won't enter the `if`
>> here but if codeLengthOf() returns `int`, then bufferLen + codeLengthOf()
>> would be negative and the `if` would be wrongly entered. I am not 100% sure
>> this is a scenario that might occur (codeLengthOf() returning large
>> "unsigned int" values) - but I'd prefer to stay on the safe side and assume
>> that it can.
>
> This is what I mean:
>
> jshell> long codeLengthOf = (long)Integer.MAX_VALUE + 1
> codeLengthOf ==> 2147483648
>
> jshell> int bufferLen = 0
> bufferLen ==> 0
>
> jshell> bufferLen + codeLengthOf <= 64
> $3 ==> false
>
> jshell> bufferLen + (int)codeLengthOf <= 64
> $4 ==> true
Yes, inserting explicit casts seems less clean than changing `codeLengthOf` to
this:
private static int codeLengthOf(char c) {
return (int) (codes[c] & 0x00000000ffffffffL);
}
There are 256 elements in constant `long[] codes`. One could easily check that
each element when ANDed with `0x00000000ffffffffL` results in a value that fits
into the first 31 bits of `int`.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8656
