Bug in Long.parseUnsignedLong

[Dmitry Nadezhin]

What is performance of Long.compareUnsigned(x, y) ?
Does HotSpot implement it as a call of Long.compare(x + MIN_VALUE, y +
MIN_VALUE) or as a single machine instruction ?



On Fri, Dec 20, 2013 at 7:53 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

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