On Tue, 25 Mar 2025 20:35:46 GMT, Volkan Yazici <vyaz...@openjdk.org> wrote:
>> Fixes endian handling `jdk.internal.net.http.websocket.Frame.Masker`. >> >> ### Implementation notes >> >> I deleted the `Frame` clone in tests, and rewired the test code depending on >> it to the actual `Frame`. To enable this, I relaxed the visibility of the >> actual `Frame`. I guess the `Frame` clone was introduced to have strict >> visibility in the actual `Frame`. Though this is not needed since the actual >> `Frame` is in an internal package. Plus, the fact that bug is in the `Frame` >> class hints in the direction that there should be one `Frame`. > > Volkan Yazici has updated the pull request incrementally with three > additional commits since the last revision: > > - Add more tests > - Guard vectorization better > - Restore the old garbage-free state src/java.net.http/share/classes/jdk/internal/net/http/websocket/Frame.java line 201: > 199: final int srcLim = src.limit(), dstLim = dst.limit(); > 200: int i = src.position(), j = dst.position(); > 201: for (; i < srcLim && j < dstLim; I meant the endian issue is in this loop - the endianness of maskBytes (currently BE) must match that of dst (all internal usages of dst is currently BE). A safeguard would be nice here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24033#discussion_r2012918848