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] [Comment Edited] (COMPRESS-411) TarUtils.formatLongOctalOrBinaryBytes never uses result of formatLongBinary
Date Sun, 18 Jun 2017 02:20:02 GMT

    [ https://issues.apache.org/jira/browse/COMPRESS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053045#comment-16053045
] 

Simon Spero edited comment on COMPRESS-411 at 6/18/17 2:19 AM:
---------------------------------------------------------------

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. I needed to make sure the byte array versions were behaving
correctly as they are needed for tests.  Unfortunately most of the methods in TarUtils are
declared public, as is the class, so the API has to be maintained, but my plan is to deprecate
them, move their bodies into a package private class in test, and delegate the functionality
to the new methods, which can remain package private (I doubt there is any especially pressing
need for classes outside of the tar implementation to call these methods. 


was (Author: sesuncedu):
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