[
https://issues.apache.org/jira/browse/COMPRESS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053045#comment-16053045
]
Simon Spero commented on COMPRESS-411:
--------------------------------------
I have a full set of fixes (apart from checking when decoding that for base256
values the most significant bytes for lengths > 8 octets are just sign
extension (i.e. 0x080 + 0x00{p} or 0xff + 0xff{p}.
The changes are mixed in with a bunch of other changes to TarUtils that are
needed for direct encoding/decoding to ByteBuffers.
> TarUtils.formatLongOctalOrBinaryBytes never uses result of formatLongBinary
> ---------------------------------------------------------------------------
>
> Key: COMPRESS-411
> URL: https://issues.apache.org/jira/browse/COMPRESS-411
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.14
> Reporter: Simon Spero
> Priority: Minor
> Fix For: 1.15
>
>
> if the length < 9, formatLongBinary is executed, then overwritten by the
> results of formatBigIntegerBinary.
> If the results are not ignored, a unit test would fail.
> Also, do the binary hacks need to support negative numbers?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
