diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-15 05:54:39 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-15 05:54:39 +0000 |
commit | 267c6f2ac71f92999e969232431ba04678e7437e (patch) | |
tree | 358c9467650e1d0a1d7227a21dac2e3d08b622b2 /external/java_websocket/patches/0001-cid-1545249-Bad-bit-shift-operation.patch | |
parent | Initial commit. (diff) | |
download | libreoffice-267c6f2ac71f92999e969232431ba04678e7437e.tar.xz libreoffice-267c6f2ac71f92999e969232431ba04678e7437e.zip |
Adding upstream version 4:24.2.0.upstream/4%24.2.0
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'external/java_websocket/patches/0001-cid-1545249-Bad-bit-shift-operation.patch')
-rw-r--r-- | external/java_websocket/patches/0001-cid-1545249-Bad-bit-shift-operation.patch | 50 |
1 files changed, 50 insertions, 0 deletions
diff --git a/external/java_websocket/patches/0001-cid-1545249-Bad-bit-shift-operation.patch b/external/java_websocket/patches/0001-cid-1545249-Bad-bit-shift-operation.patch new file mode 100644 index 0000000000..759038d8d3 --- /dev/null +++ b/external/java_websocket/patches/0001-cid-1545249-Bad-bit-shift-operation.patch @@ -0,0 +1,50 @@ +From 49a74350016b59c4cca054c5802b4437c0b3857f Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Caol=C3=A1n=20McNamara?= <caolan.mcnamara@collabora.com> +Date: Wed, 4 Oct 2023 15:19:13 +0100 +Subject: [PATCH] cid#1545249 Bad bit shift operation +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19 + +If the promoted type of the left-hand operand is int, only the five +lowest-order bits of the right-hand operand are used as the shift +distance. It is as if the right-hand operand were subjected to a bitwise +logical AND operator & (ยง15.22.1) with the mask value 0x1f (0b11111). +The shift distance actually used is therefore always in the range 0 to +31, inclusive. + +so a >>> of 32 is the same as >>> 0 so this is +result = 31 * result + (maxFrameSize ^ maxFrameSize); +i.e. +result = 31 * result + (0); + +which all looks a bit dubious. + +Working theory from https://gerrit.libreoffice.org/c/core/+/157571/1 is +that at some point maxFrameSize was a long value, and then got changed +to an int, but the hashCode() was not updated and should now read as +changed here. + + result = 31 * result + maxFrameSize; +--- + src/main/java/org/java_websocket/drafts/Draft_6455.java | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/main/java/org/java_websocket/drafts/Draft_6455.java b/src/main/java/org/java_websocket/drafts/Draft_6455.java +index 1e08448..635fa1f 100644 +--- a/src/main/java/org/java_websocket/drafts/Draft_6455.java ++++ b/src/main/java/org/java_websocket/drafts/Draft_6455.java +@@ -1150,7 +1150,7 @@ public class Draft_6455 extends Draft { + public int hashCode() { + int result = negotiatedExtension != null ? negotiatedExtension.hashCode() : 0; + result = 31 * result + (protocol != null ? protocol.hashCode() : 0); +- result = 31 * result + (maxFrameSize ^ (maxFrameSize >>> 32)); ++ result = 31 * result + maxFrameSize; + return result; + } + +-- +2.41.0 + |