> With the latest CVS, test_long and test_long_future fail on Linux,
> because float(huge) doesn't raise OverflowError but returns inf. I'm
> guessing this wasn't your intention;
Interesting. Of course it wasn't my intention, but it is relying on the
platform ldexp setting errno to ERANGE appropriately. Apparently glibc's
does not. Worse, I see the C99 standard *never* requires a conforming libm
to set errno for any call of any libm function anymore. From the C99
rationale:
In C9X, errno is no longer required to be set to EDOM or ERANGE
because that is an impediment to optimization.
The Standard has been crafted to neither require nor preclude any
popular floating-point implementation.
Fucking idiots <0.01 wink>.
This means none of Python's fp overflow checking anywhere is worth spit
anymore, not even the CHECK macro in mathmodule.c -- to the contrary, C99
*does* require overflowing libm functions to return +- HUGE_VAL, but the
CHECK macro considers that a normal (not overflow) case. Without errno to
distinguish them, it's impossible to determine whether HUGE_VAL is a normal
result or an overflow indicator. The 754 Cabal did their job well here
(i.e., they made *portable* numeric C impossible, except across 754 boxes
using C99's new 754 gimmicks).
Oh well. I don't know how to fix this in general (as above, it sounds truly
impossible to do so portably now, without platfrom #ifdefs). I expect I can
hack something together for the specific failing tests, though (which I
added specifically to find out how reliable ERANGE was -- no time like an
alpha for that!).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4