Stop raising OverflowError on underflows reported by libm (errno==ERANGE and

libm result is 0).  Cautiously add a few libm exception test cases:
1. That exp(-huge) returns 0 without exception.
2. That exp(+huge) triggers OverflowError.
3. That sqrt(-1) raises ValueError specifically (apparently under glibc linked
   with -lieee, it was raising OverflowError due to an accident of the way
   mathmodule.c's CHECK() macro happened to deal with Infs and NaNs under gcc).

1 files changed, 29 insertions, 0 deletions

diff --git a/Lib/test/test_math.py b/Lib/test/test_math.py
index 6d6bc44..1f31dc5 100644
--- a/Lib/test/test_math.py
+++ b/Lib/test/test_math.py
@@ -152,3 +152,32 @@ testit('tan(-pi/4)', math.tan(-math.pi/4), -1)
 print 'tanh'
 testit('tanh(0)', math.tanh(0), 0)
 testit('tanh(1)+tanh(-1)', math.tanh(1)+math.tanh(-1), 0)
+
+print 'exceptions'  # oooooh, *this* is a x-platform gamble!  good luck
+
+try:
+    x = math.exp(-1000000000)
+except:
+    # mathmodule.c is failing to weed out underflows from libm, or
+    # we've got an fp format with huge dynamic range
+    raise TestFailed("underflowing exp() should not have rasied an exception")
+if x != 0:
+    raise TestFailed("underflowing exp() should have returned 0")
+
+# If this fails, probably using a strict IEEE-754 conforming libm, and x
+# is +Inf afterwards.  But Python wants overflows detected by default.
+try:
+    x = math.exp(1000000000)
+except OverflowError:
+    pass
+else:
+    raise TestFailed("overflowing exp() didn't trigger OverflowError")
+
+# If this fails, it could be a puzzle.  One odd possibility is that
+# mathmodule.c's CHECK() macro is getting confused while comparing
+# Inf (HUGE_VAL) to a NaN, and artificially setting errno to ERANGE
+# as a result (and so raising OverflowError instead).
+try:
+    x = math.sqrt(-1.0)
+except ValueError:
+    pass