Hi Joe, On Jul 25, 2013, at 2:28 PM, Brian Burkhalter wrote:
>> I took a look through the code and I don't see how sdiff == >> Integer.MIN_VALUE is handled. > > This case, if compareMagnitude() does not return at lines 2668 or 2670, > intentionally falls through to line 2690. Otherwise, if hypothetically sdiff > were equal to Integer.MIN_VALUE, then evaluating line 2677 would overflow. It > is not actually apparent to me however whether line 2671 would ever be > reached were sdiff == Integer.MIN_VALUE. I have updated the comments at lines 2673 and 2682 of BigDecimal: http://cr.openjdk.java.net/~bpb/6378503/ >> In any case, as long as the runtimes and memory usage are tractable, the set >> of test cases should be augmented to include sdiff == Integer.MIN_VALUE and >> (long)Integer.MIN_VALUE + 1, etc. > > From what I can tell by inspection, sdiff mirrors the MathContext precision > (mcp) and all paths will attempt to calculate 10^e where "e" is approximately > or exactly mcp. This computation would run for days. I don't yet see a way to > test these cases. Thanks, Brian
