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

2022-05-12 Thread Pavel Rappo
On Thu, 12 May 2022 10:08:23 GMT, Daniel Fuchs wrote: >> src/java.net.http/share/classes/jdk/internal/net/http/websocket/Frame.java >> line 291: >> >>> 289: >>> 290: HeaderWriter noMask() { >>> 291: // The negation "~" sets the high order bits >> >> Rubber-stamping this in

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

2022-05-12 Thread Daniel Fuchs
On Thu, 12 May 2022 09:15:19 GMT, Pavel Rappo wrote: >> Daniel Fuchs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Revert adding char constants > > src/java.net.http/share/classes/jdk/internal/net/http/websocket/Frame.java > line 291:

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

2022-05-12 Thread Daniel Fuchs
On Thu, 12 May 2022 09:00:37 GMT, Pavel Rappo wrote: >> 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 >> >> jshel

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

2022-05-12 Thread Pavel Rappo
On Wed, 11 May 2022 18:42:46 GMT, Daniel Fuchs wrote: >> In relation to >> [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find >> here a patch that addresses possibly lossy conversions in java.net.http > > Daniel Fuchs has updated the pull request incrementally with one

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

2022-05-12 Thread Pavel Rappo
On Thu, 12 May 2022 08:56:26 GMT, Daniel Fuchs 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

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

2022-05-12 Thread Daniel Fuchs
On Thu, 12 May 2022 08:42:39 GMT, Daniel Fuchs wrote: >> 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

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

2022-05-12 Thread Daniel Fuchs
On Wed, 11 May 2022 20:31:00 GMT, Michael McMahon 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

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

2022-05-11 Thread Michael McMahon
On Wed, 11 May 2022 17:10:45 GMT, Daniel Fuchs wrote: >> src/java.net.http/share/classes/jdk/internal/net/http/hpack/QuickHuffman.java >> line 739: >> >>> 737: buffer |= (codeValueOf(c) >>> bufferLen); // >>> append >>> 738: bufferLen += (int) le

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

2022-05-11 Thread Roger Riggs
On Wed, 11 May 2022 18:33:44 GMT, Daniel Fuchs wrote: >> So if x is a char, ~x seems to be an int :-( > > I have reverted adding constant fields. Too bad - the casts are back. Phooey: Sorry to have lead you astray. :( And casting before `~` does the same not wanted result. - PR:

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

2022-05-11 Thread Daniel Fuchs
> In relation to > [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find > here a patch that addresses possibly lossy conversions in java.net.http Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: Revert adding