BigInteger

[Aleksy Schubert <alx at cs dot ru dot nl>]

Dear all,

I'm just analysing carefully the code of java.math.BigInteger. I've
got some interesting observations which might be of use for you.
They may mean possible bugs or flaws in the source code of the class. 
So, here are my observations.

The constructor

 public BigInteger(int signum, byte[] magnitude)

basically constructs the integer based on the array of bytes.
It tries to contract the array of integers, but in fact it
does that only provided that the number represented by
magnitude can fit into 32 bits.

Similarly, the method toByteArray() seems to try to return a byte
array which is as short as possible, but the bitLength() method
does not give the minimal number of bits which is needed to fit
the actual number, but it analyses the the highest integer only.

To see the consequences, consider the following example.

Suppose we start with the following array of bytes:

a = { 32, 33, 34, 35, 36, 37, 0, 0, 0, 0, 0, 0 }

integer = new BigInteger(a)

returns a number with integer.words.length==3 and
b = integer.toByteArray() gives the result

{ 32, 33, 34, 35, 36, 37, 0, 0, 0 }

which is a bit unexpected.

My basic question is if you consider this behaviour OK (Sun's specs
say nothing about situations like this), a flaw which can be repaired
at some point in the future, a flaw the correction of which is
important/urgent or simply a bug.

Bests,
Aleksy

--
De toekomst is onzeker en het einde is altijd nabij
- Roadhouse Blues, The Doors