[Jack Jansen] > I found a couple of references to INFINITY being a float. ... Yes, INFINITY must expand to a constant expression of type float, although your compiler isn't doing that (see below). The header files you're using are still braindead for the reasons I explained last time regardless. >> #define Py_HUGE_VAL ((double)INFINITY) > Is the intention of this define that it would first convert the > constant "1e50" to an IEEE float "Infinity", and that this float > would then be promoted to a double "Infinity"? No. As the comments before this code said, the explicit cast to double was for the benefit of some other broken compiler. The literal "1e50" has type double in C, so if they're really #define'ing INFINITY as 1e50 then they're violating that INFINITY must expand to an expression of type float. They could have made it a float literal by appending "f" or "F", but then it wouldn't be a legal float literal. They're screwed either way -- they're doing this part incorrectly no matter how you cut it. They can look at any other compiler for a correct way to do it <wink>. > If it is indeed stated somewhere in the C standard that this is the > course of action to take then the compiler is wrong, The compiler is wrong, but for other reasons. > because what it actually seems to be doing is parsing the "1e50" as a > double because of the cast (speculating here, but this is consistent > with the results). 1e50 is a double with or without the cast. > The patch is a simple > #ifdef __APPLE__ > #undef INFINITY > #endif Bleech. I'm going to remove all this crap. If some Crays still have broken HUGE_VAL definitions, tough -- someone on a Cray can fix it. Putting this junk in the core just ensures it will always stay broken.
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