Hi,

On OpenBSD 4.4, the test_math.py regression test fails with the following:

Traceback (most recent call last):
  File "Lib/test/test_math.py", line 419, in testLog
    self.assertRaises(ValueError, math.log, NINF)
AssertionError: ValueError not raised

This is because libm's log function does not return NaN when passed
-INFINITY. It returns -INFINITY and sets EDOM. This behaviour seems to
be permitted by the C99 spec (ISO/IEC 9899:1999):

> 7.12.1 Treatment of error conditions
> paragraph2:
> ... On a domain error, the function returns an implementation-defined
> value; if the integer expression math_errhandling & MATH_ERRNO is 
> nonzero, the integer expression errno acquires the value EDOM; 

in mathmodule.c:math_1() errno seems to be deliberately ignored when the
result is infinite. The attached patch modified math_1() to retain EDOM
errors for infinite results.

It's possible that this patch would cause breakage on other systems: 
there's a reason that errno is currently ignored, which is that it can't
be trusted on all systems (notably Linux: on one Linux system I've used
of three different evaluations, all of log singularity type (log(0),
log1p(-1), atanh(1), ...), one gave errno=EDOM, one gave errno=ERANGE,
and one didn't set errno at all).

So I'm reluctant to mess with math_1, especially this close to a release.

An alternative solution would be to check special cases for log directly
within the mathmodule.c code, only passing positive nonspecial arguments
to the system log function.  This would have a much lower risk of
causing breakage on other systems.  Note that Solaris with Sun's
compiler also has some problems with log:  depending on compiler
options, etc., log(-1.0) can give -inf instead of nan.  So having Python
deal with log special cases directly seems like a good thing to do there
as well.

Damien, if you're still there:

Please could you try the patch "math_log.patch" attached to issue 3167, 
and let me know whether it fixes the test failure?

I've committed the issue 3167 fix in revisions r67707 to r67710.
I'm fairly sure that this patch should resolve this issue.  (Let me know 
if it doesn't.)