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