[Jack Jansen] > I think there is a problem with the way pyport.h treats HUGE_VAL and > INFINITY. I'm afraid there are necessarily problems there, since this stuff is insufficiently standardized. > But as this whole area is a great can of worms I'd like someone with > more knowledge of C standards and floating point and such to ponder it, > please. Let's look at the code: """ /* According to * http://www.cray.com/swpubs/manuals/SN-2194_2.0/html-SN-2194_2.0/x3138.htm * on some Cray systems HUGE_VAL is incorrectly (according to the C std) * defined to be the largest positive finite rather than infinity. We * need the std-conforming infinity meaning (provided the platform has * one!). * * Then, according to a bug report on SourceForge, defining Py_HUGE_VAL as * INFINITY caused internal compiler errors under BeOS using some version * of gcc. Explicitly casting INFINITY to double made that problem go * away. */ #ifdef INFINITY #define Py_HUGE_VAL ((double)INFINITY) #else #define Py_HUGE_VAL HUGE_VAL #endif """ > If both INFINITY and HUGE_VAL are defined then INFINITY takes > precedence. Right, and the comment explains why (a broken Cray system). > However, all references I've seen to INFINITY seem to indicate that > this is a float value, not a double value, according to the C99 standard. It is a float value, but is explicitly cast to double in the above. > And I've now come across a platform where HUGE_VAL==1e500 and > INFINITY==HUGE_VALF==1e50, and these latter values are not infinite for > doubles (I assume they are infinite for floats, but I haven't checked). The platform's header files are braindead. That doesn't mean we shouldn't try to survive despite them, but you should file a bug report with whoever supplies this C. If (double)INFINITY isn't a double-precision infinity, their definition of INFINITY is hosed (the C89 std doesn't say anything useful about this, it's a matter of respecting the spirit of IEEE-754 and that C didn't bother to define a double-precision version of the INFINITY macro -- that means a *useful* float INFINITY has to be defined in such a way that it can do double-duty). > I have a patch that will fix this problem for my specific case, but I > have the feeling that it may be the pyport.h logic that is at fault > here. If no-one jumps in I'll commit my fix in a few days time. Don't check in a change here without review. Why are you keeping "the fix" secret? At this point, I'd be happy to drop the hack-around for the broken Cray, and reduce the whole mess to: #ifndef Py_HUGE_VAL #define Py_HUGE_VAL HUGE_VAL #endif Then someone on a broken box can #define their own Py_HUGE_VAL in their own stinkin' config file.
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