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

[Daniel Fuchs]

On Wed, 11 May 2022 20:31:00 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I believe the method returns an "unsigned int" - having the method return an int would then potentially cause `bufferLen + len <= 64` to yield true when it shouldn't. Hopefully @pavelrappo will comment.
>
> codeLengthOf() returns long. It could be changed to return int with a cast internally and then you could avoid the two new casts.

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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8656