[Python-Dev] HUGE_VAL and INFINITY

Jack Jansen Jack.Jansen@oratrix.com
Tue, 2 Jul 2002 22:32:33 +0200


On dinsdag, juli 2, 2002, at 05:28 , Tim Peters wrote:

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

I found a couple of references to INFINITY being a float. Here's 
one (no idea as to it's status, though, that's why I asked for 
help of a standards guru): 
http://www.opengroup.org/onlinepubs/007904975/basedefs/math.h.html
(googling for "INFINITY math.h" will find many more).

> #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"? If it is indeed 
stated somewhere in the C standard that this is the course of 
action to take then the compiler is wrong, 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).
If you happen to have a reference then I can post a bug report.

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

The patch is a simple
#ifdef __APPLE__
#undef INFINITY
#endif

I'll post a sourceforge bug tomorrow and assign it to you. Feel 
free to completely ignore it and do the config magic to handle 
the Cray case specially, though.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -