[
https://issues.apache.org/jira/browse/CODEC-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565425#action_12565425
]
Julien Aymé commented on CODEC-61:
----------------------------------
An easier way to fix this bug would be to declare lengthDataBits as a long, and
cast the other to int:
long lengthDataBits = ((long)binaryData.length) * EIGHTBIT;
int fewerThan24bits = (int) (lengthDataBits % TWENTYFOURBITGROUP);
int numberTriplets = (int) (lengthDataBits / TWENTYFOURBITGROUP);
> Base64.EncodeBase64() thows NegativeArraySizeException on large files
> ---------------------------------------------------------------------
>
> Key: CODEC-61
> URL: https://issues.apache.org/jira/browse/CODEC-61
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.3
> Environment: java -version
> java version "1.5.0_03"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
> Java HotSpot(TM) Server VM (build 1.5.0_03-b07, mixed mode)
> uname -a
> Linux HP-FC7-IGOR 2.6.23.8-34.fc7 #1 SMP Thu Nov 22 20:39:56 EST 2007 x86_64
> x86_64 x86_64 GNU/Linux
> Reporter: Igor Slepchin
> Fix For: 1.4
>
>
> The NegativeArraySizeException exception is thrown by Base64.EncodeBase64()
> for arrays larger than 268435455 bytes (2^31/8-1).
> public static byte[] encodeBase64(byte[] binaryData, boolean isChunked)
> starts with the following three lines:
> int lengthDataBits = binaryData.length * EIGHTBIT;
> int fewerThan24bits = lengthDataBits % TWENTYFOURBITGROUP;
> int numberTriplets = lengthDataBits / TWENTYFOURBITGROUP;
> The first of the lines will cause an integer overflow in lengthDataBits for
> lengths larger than 2^31/8-1, making it a negative number. The fix is trivial
> (but not tested on the running code, I just ran through a few numbers to
> validate that it computes the same results as the original code):
> int lengthData = binaryData.length;
> int fewerThan24bits = lengthData % (TWENTYFOURBITGROUP / EIGHTBIT) *
> EIGHTBIT;
> int numberTriplets = lengthData / (TWENTYFOURBITGROUP / EIGHTBIT);
> This way the encoder will be able to process files of up to 2^31-1 bytes in
> length, which is much better than ~250MB.
> The issue was found in commons 1.3; the source code above was taken from SVN
> trunk so I assume it's still present in 1.4:
> http://svn.apache.org/repos/asf/commons/proper/codec/trunk/src/java/org/apache/commons/codec/binary/Base64.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
