[Python-bugs-list] [ python-Bugs-640554 ] Overflow in Objects/floatobject.c

[noreply@sourceforge.net]

Bugs item #640554, was opened at 2002-11-19 03:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640554&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nick Maclaren (nmm1)
>Assigned to: Tim Peters (tim_one)
Summary: Overflow in Objects/floatobject.c

Initial Comment:
Objects/floatobject.c has a bug on systems where
converting a double
into a long but where it doesn't fit causes a trap. 
The following
fix is generic:

*** Objects/floatobject.c.org   Sun May 12 18:20:38
2002
--- Objects/floatobject.c       Mon Nov 18 20:20:28
2002
***************
*** 656,662 ****
           to long may yield gibberish in either case. 
What really matters
           is whether converting back to double again
reproduces what we
           started with. */
!       aslong = (long)wholepart;
        if ((double)aslong == wholepart)
                return PyInt_FromLong(aslong);
        PyErr_SetString(PyExc_OverflowError, "float too
large to convert");
--- 656,664 ----
           to long may yield gibberish in either case. 
What really matters
           is whether converting back to double again
reproduces what we
           started with. */
!         aslong = (wholepart >= LONG_MIN && wholepart
<= LONG_MAX ?
!             (long)wholepart :
!             0);
        if ((double)aslong == wholepart)
                return PyInt_FromLong(aslong);
        PyErr_SetString(PyExc_OverflowError, "float too
large to convert");


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

>Comment By: Tim Peters (tim_one)
Date: 2002-11-24 00:11

Message:
Logged In: YES 
user_id=31435

Python isn't in favor of silent errors either, although what we 
can do in the way of detecting numeric errors is 
complicated by the lack of uniformity across C 
environments -- it's also complicated by people using 
oddball compiler options <0.7 wink>.

I checked in a change similar to this one, but with strict 
inequality in the guard on the cast to long:  if a long has 
more bits of precision than a double (as is common on 64-
bit machines), then, e.g., wholepart <= LONG_MAX may be 
true even if wholepart is mathematically equal to 
LONG_MAX + 1 (C may round up LONG_MAX to 
LONG_MAX+1 due to the implicit cast to double the 
comparison requires).  So in that case you'd get a trap 
despite the guard, because LONG_MAX+1 is too large to 
cast to long.  Testing wholepart < LONG_MAX instead 
prevents that, albeit at the cost of returning a Python long 
when wholepart is mathematically equal to LONG_MAX on a 
box where a long has no more bits of precision than a 
double.

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

Comment By: Nick Maclaren (nmm1)
Date: 2002-11-20 18:23

Message:
Logged In: YES 
user_id=652073

Solaris with -fptrap=common.  What I am setting as the
default on our systems (and shall see how many people
screech).  It was also possible in Norcroft C on Phoenix
(all right, that IS obscure) and I have been told that it
is fairly widespread (though not the norm) in embedded
compilers.  There are others, though it is rarely the
default.

You may gather how long I have been in this game when I say
that I remember when a large number of systems trapped
integer overflow by default :-)  I still have the very
old-fashioned view that a clean failure is better than
wrong answers ....


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

Comment By: Tim Peters (tim_one)
Date: 2002-11-19 20:55

Message:
Logged In: YES 
user_id=31435

I'm curious:  which system do you have in mind?  I 
understand that it's possible, and agree with your 
proposed fix.  I've simply never bumped into a system that 
did a raise a trap,

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

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