commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Spero (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COMPRESS-411) TarUtils.formatLongOctalOrBinaryBytes never uses result of formatLongBinary
Date Sun, 18 Jun 2017 01:47:00 GMT

    [ 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)

Mime
View raw message