garydgregory commented on code in PR #685:
URL: https://github.com/apache/commons-compress/pull/685#discussion_r2265439816
##########
src/main/java/org/apache/commons/compress/archivers/ar/ArArchiveInputStream.java:
##########
@@ -147,24 +140,22 @@ public ArArchiveInputStream(final InputStream
inputStream) {
super(inputStream, StandardCharsets.US_ASCII.name());
}
- private int asInt(final byte[] byteArray, final int offset, final int len)
throws IOException {
- return asInt(byteArray, offset, len, 10, false);
+ private int asOptionalDecimal(final byte[] byteArray, final int offset,
final int len) throws IOException {
Review Comment:
> I renamed/added these methods because I slightly changed how `ar` entries
are parsed.
>
> Previously, GNU string table entries were handled differently from other
`ar` entries:
>
> * For GNU string table entries, only the length and name fields were
parsed, since the other fields are usually blank.
> * For all other entries, every header field was parsed.
>
> In this PR, I introduced a unified `parseEntry` method that parses both
kinds of members. The new `asOptionalDecimal`, etc., methods handle cases where
numeric fields are blank (as they often are for the GNU string table).
>
> Initially, I considered adding an `if` to skip parsing `mtime`, `uid`,
`gid`, and `mode` for GNU string table entries. But those fields aren’t
critical even for normal files, so it’s cleaner to parse them as optional and
avoid throwing conversion exceptions when they’re blank.
>
> What do you think? Should we keep the original parsing logic or relax it?
All of the above doesn't answer my question. I think we leave the behavior
as is.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
