On Mon, 17 Mar 2025 07:52:43 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 one additional > commit since the last revision: > > Apply review feedback on naming in `Masker` > > `reset` -> `setMask` > `initGallopingMask` -> `initVectorMask` > `applyGallopingMask` -> `applyVectorMask` Hi, original filer here. I don't know how you handle such things here, but 24 files changed seems somewhat excessive to me for this bug. I do not know how effective the long-optimization realy is because/when data is not 8-byte-aligned. But if one wants to implement it, be sure to apply *native* endianess for the mask-long, the input (eg. via a slice) and the buffer. If one uses the java default big endian (aaargh...), and "happens" to run on a little endian machine, the "optimization" would have to do a byte swap to native endian on read, do the masking and byteswap again on the way out. (same is true when choosing little endian and running on big endian hardware, although i would like the chances there much better ;-)) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24033#issuecomment-2730335475
