On Sun, 6 Oct 2024 15:53:55 GMT, Eirik Bjørsnøs <[email protected]> wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> copyright
>
> src/java.base/share/classes/java/util/zip/ZipUtils.java line 195:
>
>> 193: * The bytes are assumed to be in Intel (little-endian) byte order.
>> 194: */
>> 195: public static final long get64(byte[] b, int off) {
>
> This method returns a signed 64 bit value, which I think is not what some of
> its call sites expect. It should in any case be renamed to `get64S` to align
> with `get32S`. A new method `get64` should be introduced and any call site
> expecting unsigned numbers (most?) should use that instead.
>
> If you don't want to deal with this in this PR, I could file an issue and
> suggest a PR for this. Let me know.
As it's a pre-existing issue I'd prefer to keep this one focused on the
switch-over. How would you model unsigned long values here, though? Sure we
could read into a `BigInteger` or accept negative values, but to really support
such overflows we might have to rework a lot of things.
FWIW we already cap some values even lower in practice:
end.centot = (int)centot64; // assume total < 2g
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789215898
