classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Bug in Long.toOctalString


From: Eric Blake
Subject: RE: Bug in Long.toOctalString
Date: Fri, 20 Jul 2001 08:44:52 +0100

> -----Original Message-----
> From: Mark Wielaard [mailto:address@hidden
> Sent: 19 July 2001 22:10
> To: Eric Blake
> Cc: classpath
> Subject: Re: Bug in Long.toOctalString
>[...]
> Your version of looks a lot like the version used in libgcj.
> They use a char[] which seems a bit more efficient then using
> a StringBuffer, but your version uses the digit[] which seems
> more efficient then their use of Character.forDigit().
> Maybe we can merge the two versions of Long while fixing these bugs?
> I saw Tom Tromey was already working on Boolean and Integer.
>
My version was more or less from Integer.toUnsignedString, except that I
calculated the mask once instead of in the loop (which means the version in
Integer can be optimized, too).  Also, (int)l & mask is more efficient than
(int)(l & mask), as the VM then does not have to expand mask to a long,
perform 64 bit math, and chop it back down.

Feel free to change it to whatever is most efficient; I just wanted to get
rid of the bug.  One thought I did have would be moving the digit[] field to
Number and giving it default access, so that both Long and Integer can use
the same inherited object rather than repeating efforts.

I also noticed that the compareTo methods in both Long and Integer have a
bug - subtraction only produces a valid result if the answer doesn't
overflow.  For example,
  new Integer(0).compareTo(new Integer(Integer.MIN_VALUE));
should be positive, but currently comes out negative.  But I haven't yet had
time to rewrite them.

--
Eric Blake, Elixent, Castlemead, Lwr Castle St., Bristol BS1 3AG, UK
address@hidden   tel:+44(0)117 917 5611




reply via email to

[Prev in Thread] Current Thread [Next in Thread]