Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)

[Tim Peters]

We need a glibc expert!  Anyone qualify?

[Huaiyu Zhu]
> ...
> This is very likely to be a 2.0 bug.

Or a 1.5.2 bug.  I have to keep saying this stuff is a platform-dependent
crap shoot, because it is (I too prefer that Python underflow silently by
default, though).

> Just to make sure, I have used freshly downloaded source code of
> both 1.5.2 and 2.0b2, then

> ./configure
> make
> ./python
>
> from math import *
> exp(-746)
>
> I got 0.0 from 1.5.2 but OverflowError: math range error from 2.0b2.
>
> The file mathmodule.c has quite some differences between the two versions,
> mostly related to the ANSIfication.  I'm not sure where the problem is.

It's not in mathmodule.c.

> I haven't tried the 2.0c1 yet, as the site is not available.  Can
> other Unix users confirm this behavior?

I went over to Guido's and forced him to try it.  He sees the same behavior:
after building 1.5.2 and some flavor of 2.0 w/ the same gcc and libraries,
1.5.2 Python silently returns 0 and (some flavor of) 2.0 raises
OverflowError.

But there is no code in Python that accounts for the difference.  Running it
under the debugger, the platform exp leaves errno at 0 under 1.5.2 but sets
errno to ERANGE (34) under 2.0.  Since the platform exp was the only
conceivable cause for this difference, it's not surprising that the debugger
confirmed that the platform exp is in fact the cause.

So the remaining question is why the same exp from the same library has
different errno behavior depending on which version of Python it's called
from.  *That* one we couldn't answer, after a fruitless time digging thru
the Byzantine glibc source code trying to reverse engineer it.  Their exp
*can* display different error behavior at runtime depending on several
obscure things, but they're too obscure to relate back clearly to anything
Python is doing.

The 2.0 behavior (set errno to ERANGE on exp underflow) appears to be what
the glibc exp author believes POSIX mandates, and is one of their exp's
possible runtime behaviors, and your own little C program (which you posted
earlier) suggests that's the default behavior under gcc + glibc.  So
presumably 1.5.2 config was such as to inhibit the default behavior.
However, nobody changed this on purpose, so it smells like an unintended
side effect of some other (currently unknown) config change.

I don't know what to do next.  I can't pursue it myself, and you've seen
from the lack of replies to your posts that I'm the only who'll even listen
to you <wink>.  Guido suggests that one big change in 2.0 is that we're
including a lot more std headers than we used to.  It could well be that one
of those #defines some God-forsaken preprocessor symbol one of whose five
meanings (documented or not) is "use POSIX-conformant libm error reporting",
but which someone #include'd in 2.0 to make (who knows?) sockets work right
on some other flavor of Unix.  Don't know.  Unix config is a mess, and so is
glibc.  Best hope now is for someone intimately familiar with glibc
internals to jump in and own this.

staring-at-the-python-source-remains-pointless-for-this-one-ly y'rs  - tim