[Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)

[Huaiyu Zhu]

[Tim Peters]

> We need a glibc expert!  Anyone qualify?

If there is none here, maybe someone cares to ask in some gcc or gnu news
groups?

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

So can we set a flag to explicitly discount ERANGE?  There are only 19 lines
in the source code that contain ERANGE, and 8 lines containing math_error.
All the latter are in Modules/{c,}mathmodule.c.  Could we just add an ifdef
IEEE754 on these 8 lines?  This would go a long way to aleviate this problem
before we find a perfect solution, if there is one.

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

I'm not interested in where this comes from - the only thing that matters is
that it worked in 1.5.2 and breaks in 2.0.  Whether the 1.5.2 behavior was
intended or not, it's not a bug.  The 2.0 behavior is a bug.  If Posix
conflicts with IEEE floating point arithmetic, then confirming to Posix in
this regard is a bug.

I would suggest the next thing to do is to introduce an IEEE754 flag and let
those who do not like it to voice their opinions.  Since this is the same
behavior as 1.5.2 I doubt any running code would be broken by this.

Huaiyu