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 Fri, 16 Jun 2017 20:57:00 GMT

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

Simon Spero commented on COMPRESS-411:
--------------------------------------

I have fixed various issues in the handling of base256 encoded long numbers (I saw that negative
numbers are used for STAR timestamps from before the epoch).

One of the issues involved the maximum size of a number.  The number of bits available to
represent the number is one less than the total number of bits available.  Thus, an eight
byte field can hold up to a 63 bit 2's-complement integer.  
Further, the range of such a number is from -2 ^n-1^ to 2 ^n-1^ -1 , which can cause range
overflows.  

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