Bug in Long.parseUnsignedLong

[Louis Wasserman]

@Paul Sandoz: Is there a particular reason you prefer an extra division to
the cache?


On Fri, Dec 20, 2013 at 8:54 AM, Dmitry Nadezhin
<dmitry.nadezhin at gmail.com>wrote:

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



-- 
Louis Wasserman