Bug in Long.parseUnsignedLong

[Paul Sandoz]

Hi Brian,

It would be nice to avoid the caches, on a hunch i am wondering if the following will work:

  long result = first * radix + second;
  if ((first >>> 1) > (Long.MAX_VALUE / radix) ||  // possible overflow of first * radix
    Long.compareUnsigned(result, first) < 0) {  // overflow of  first * radix + second

It should be possible to write some tests creating strings in the appropriate base to select the appropriate value for first will kick off an overflow.

Paul.
 
On Dec 19, 2013, at 9:21 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Here's a formalization of the suggested fix:
> 
> http://cr.openjdk.java.net/~bpb/8030814/webrev/
> 
> It works against the test case.
> 
> Brian
> 
> On Dec 19, 2013, at 11:26 AM, Brian Burkhalter wrote:
> 
>> Upon inspection only that indeed looks correct.
>> 
>> Thanks …
>> 
>> On Dec 19, 2013, at 10:28 AM, Louis Wasserman wrote:
>> 
>>> Here's one approach that works: there is overflow iff 
>>> 
>>> compareUnsigned(first, divideUnsigned(MAX_UNSIGNED, radix)) > 0 || (first == divideUnsigned(MAX_UNSIGNED, radix) && second > remainderUnsigned(MAX_UNSIGNED, radix));
>>> 
>>> Since radix <= Character.MAX_RADIX, you can precompute the divides and remainders in a small table.
>> 
>