[Python-bugs-list] [ python-Bugs-815062 ] Py_OVERFLOWED should be isinf() on openbsd

[SourceForge.net]

Bugs item #815062, was opened at 2003-09-30 08:09
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
>Assigned to: Michael Hudson (mwh)
Summary: Py_OVERFLOWED should be isinf() on openbsd

Initial Comment:
test_long and test_complex both fail on OpenBSD/x86.

The problem is essentially that:



>>> shuge = '12345' * 120 

>>> float(int(shuge))

Inf



while on everything else, this raises an OverflowError.



Making the #ifdef in Include/pyport.h that sets

Py_OVERFLOWED to isinf() also do the same for OpenBSD

fixes this. I'm proposing to fix this for 2.3.2,

because then we're passing all tests on openbsd (minus

the wackiness from the HP testdrive boxes).



Tim, is there any reason to not add an autoconf test

for the presence of isinf(), and always use it for

Py_OVERFLOWED if it's present? Using it on this Redhat

9 system doesn't seem to break anything (well, the test

suite passes).



Obviously not going to make the latter change for

2.3.2, but is it appropriate for the trunk?



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-09-30 09:31

Message:
Logged In: YES 
user_id=31435

I can't like the #ifdef solution because C99 says HUGE_VAL is 

returned in overflow cases, not necessarily an infinity.  That's 

why the original macro checks against HUGE_VAL instead of 

using Py_IS_INFINITY(X) (btw, replacing *that* with isinf() 

when possible would be wholly unobjectionable).



Michael, the reason optimization level makes a difference is 

probably an optimization bug:  some platforms define 

HUGE_VAL as a God-awful casted mess, so complicated that 

their own compilers can't deal with it correctly.  So it's 

possible that #define'ing Py_HUGE_VAL to a saner expression 

on this platform would have solved the problem too; as the 

comments before Py_HUGE_VAL say, we use Py_HUGE_VAL 

instead of HUGE_VAL because some platforms screw up 

HUGE_VAL.



An experiment:  with the original definition of 

Py_OVERFLOWED, try #define'ing



#define Py_HUGE_VAL ((double)(HUGE_VAL))



on this box and see what happens.  The thinking is that if 

HUGE_VAL expands to a float expression on this box, 

optimization is most likely to screw up an implicit conversion 

to double; making that conversion explicit may worm around 

an optimization bug then.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-30 09:09

Message:
Logged In: YES 
user_id=6656

it's compiler bogusness, it seems, unless the code in

PyLong_AsDouble is non-ansi in some way that currently

escapes the eye.  compiling -O2 or higher makes test_long

fail; -O or lower makes it pass.



gcc is 2.95.3 fwiw.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-09-30 08:41

Message:
Logged In: YES 
user_id=6656

while setting Py_OVERFLOWED to use isinf does indeed make

the tests pass on openbad, i'd be happier if i understood

why the other definition *doesn't* work...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 08:23

Message:
Logged In: YES 
user_id=29957

--- pyport.h    4 Sep 2003 11:59:50 -0000       2.63

+++ pyport.h    30 Sep 2003 12:22:14 -0000

@@ -258,7 +258,7 @@

  *    X is evaluated more than once.

  * Some platforms have better way to spell this, so expect

some #ifdef'ery.

  */

-#ifdef __FreeBSD__

+#if defined(__FreeBSD__) || defined(__OpenBSD__)

 #define Py_OVERFLOWED(X) isinf(X)

 #else



makes test_long and test_complex pass on OpenBSD.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815062&group_id=5470