You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Glavo (via GitHub)" <gi...@apache.org> on 2024/11/25 04:12:05 UTC
[PR] Optimizing ZipEightByteInteger [commons-compress]
Glavo opened a new pull request, #614:
URL: https://github.com/apache/commons-compress/pull/614
Use unsigned long instead of BigInteger to simplify code and improve performance.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Optimizing ZipEightByteInteger [commons-compress]
Posted by "garydgregory (via GitHub)" <gi...@apache.org>.
garydgregory merged PR #614:
URL: https://github.com/apache/commons-compress/pull/614
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Optimizing ZipEightByteInteger [commons-compress]
Posted by "Glavo (via GitHub)" <gi...@apache.org>.
Glavo commented on PR #614:
URL: https://github.com/apache/commons-compress/pull/614#issuecomment-2500918734
> This means the max value for an unsigned 8 byte field is `18,446,744,073,709,551,615`, which does not fit in a Java `long`.
Let me explain this in more detail.
Although byte, short, int, and long are treated as signed by default, they are essentially just 1, 2, 4, or 8 bytes, and the specific semantics depends on what the user thinks they are.
Since Java does not have unsigned integers, it is a common and standard practice to give unsigned semantics to byte, short, int, and long. A notable example is that [JDK-4504839](https://bugs.openjdk.org/browse/JDK-4504839) and [JDK-6322074](https://bugs.openjdk.org/browse/JDK-6322074) added methods to the standard library to help users more easily operate on these integer values with unsigned semantics. In addition, methods such as `ByteBuffer#getLong` do essentially the same thing.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Optimizing ZipEightByteInteger [commons-compress]
Posted by "Glavo (via GitHub)" <gi...@apache.org>.
Glavo commented on PR #614:
URL: https://github.com/apache/commons-compress/pull/614#issuecomment-2500839275
> Please rebase on git master to pick up `ZipEightByteIntegerTest.testBIFromMaxValue()`.
Done. This PR can pass this test.
> This means the max value for an unsigned 8 byte field is `18,446,744,073,709,551,615`, which does not fit in a Java `long`.
We just need to use negative numbers to represent values greater than `Long.MAX_VALUE`.
This is a standard practice, and `Long` also provides some convenient methods to operate these unsigned longs, such as [`toUnsignedString`](https://docs.oracle.com/javase/8/docs/api/java/lang/Long.html#toUnsignedString-long-).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Optimizing ZipEightByteInteger [commons-compress]
Posted by "garydgregory (via GitHub)" <gi...@apache.org>.
garydgregory commented on PR #614:
URL: https://github.com/apache/commons-compress/pull/614#issuecomment-2501051955
@Glavo
OK, ty, for the explanations 👍 I'll merge when the builds finish green.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Optimizing ZipEightByteInteger [commons-compress]
Posted by "Glavo (via GitHub)" <gi...@apache.org>.
Glavo commented on PR #614:
URL: https://github.com/apache/commons-compress/pull/614#issuecomment-2500859403
I added some more tests to prove that `getLongValue` and `toString` still behave the same way for very large numbers.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Optimizing ZipEightByteInteger [commons-compress]
Posted by "garydgregory (via GitHub)" <gi...@apache.org>.
garydgregory commented on PR #614:
URL: https://github.com/apache/commons-compress/pull/614#issuecomment-2500779909
Hello @Glavo
I believe this PR breaks the ZIP specification. The package may not be in full compliance either.
Please rebase on git master to pick up `ZipEightByteIntegerTest.testBIFromMaxValue().
In https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT, I read
```
4.4.1.1 All fields unless otherwise noted are unsigned and stored in Intel low-byte:high-byte, low-word:high-word order.
```
This means the max value for an unsigned 8 byte field is `18,446,744,073,709,551,615`, which does not fit in an Java `long`.
WDYT?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org