RFR: 8286386: Address possibly lossy conversions in java.net.http [v5]

[Pavel Rappo]

On Thu, 12 May 2022 08:56:26 GMT, Daniel Fuchs <dfuchs at 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