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

Category: Python Interpreter Core Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nick Maclaren (nmm1) Assigned to: Nobody/Anonymous (nobody) Summary: Minor FP bug in object.c

Initial Comment: This is closely related to the one I have reported in floatobject.c (789159). VERY closely. It is shown up by the following test on a machine with 64-bit longs and floating-point trapping turned on (though it might show up as bogus results even with no trapping):

print int( 9223372036854775200.0) print int( 9223372036854775800.0) print int(-9223372036854776800.0) print int(-9223372036854777000.0)

958,959c958,959 < double intpart, fractpart; < int expo; ---

978c978,989 < if (intpart > LONG_MAX || -intpart > LONG_MAX) { ---

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

Date: 2004-03-14 23:27

Message: Logged In: YES user_id=31435

Nick, that helps (thanks!), but I still don't understand the connection between your examples and the patch. The patch is indeed to _Py_HashDouble(), but that shouldn't get executed when doing, e.g.,

print int(9223372036854775200.0)

Is there a relationship between the examples and the patch, or do the examples belong to some other bug report?

Or is another assumption here that you're typing those examples in to an interactive Python shell? *Then* _Py_HashDouble() would get called, as part of compilation.

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

Comment By: Nick Maclaren (nmm1) Date: 2004-03-09 07:20

Message: Logged In: YES user_id=652073

The bug is overflow (i.e. undefined behaviour), and so the symptoms will vary according to the system. Under the conditions I was running, there was no output, because Python terminated with a SIGFPE. As I said, it could as easily show up as erroneous results.

In THIS case, the failure occurs in the input processing, and the purpose of prefixing it by print and int() is if you try it on a system where it gives wrong answers. If you don't have access to a system where overflow can be turned on or one that uses unusual arithmetic, you will not be able to repeat it. That is why I created a fix.

The reason that I didn't attach is is that attachment was broken; I don't know why, and have neither the time nor the inclination to debug a Web interface that I do not manage. I can trivially send such things by Email, which is far more reliable. There doesn't appear to be a mechanism to try again, so here is a context diff:

*** object.c.org Wed Feb 19 03:21:21 2003 --- object.c Fri Aug 15 15:22:50 2003 *************** *** 955,962 **** long _Py_HashDouble(double v) { ! double intpart, fractpart; ! int expo; long hipart; long x; /* the final hash value */ /* This is designed so that Python numbers of different types --- 955,962 ---- long _Py_HashDouble(double v) { ! double intpart, fractpart, z; ! int expo, i, j; long hipart; long x; /* the final hash value */ /* This is designed so that Python numbers of different types *************** *** 975,981 **** #endif if (fractpart == 0.0) { /* This must return the same hash as an equal int or long. */ ! if (intpart > LONG_MAX || -intpart > LONG_MAX) { /* Convert to long and use its hash. */ PyObject *plong; /* converted to Python long */ if (Py_IS_INFINITY(intpart)) --- 975,992 ---- #endif if (fractpart == 0.0) { /* This must return the same hash as an equal int or long. */ ! /* Remember that (double)LONG_MAX can round either way. */ ! if (intpart > LONG_MIN/2 && intpart < LONG_MAX/2) ! z = 0.0; ! else { ! z = (intpart >= 0.0 ? intpart : -intpart); ! for (i = (sizeof(long)*CHAR_BIT-1)/16; i >= 0; --i) { ! x = LONG_MAX; ! for (j = 0; j < i; ++j) x

! z -= ldexp(x&0xffff,16*i); ! } ! } ! if (z > 0.0) { /* Convert to long and use its hash. */ PyObject *plong; /* converted to Python long */ if (Py_IS_INFINITY(intpart))

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

Comment By: Tim Peters (tim_one) Date: 2004-02-16 19:22

Message: Logged In: YES user_id=31435

Sorry, I can't make for this, so unassigned it.

To help the next person,

1. Please say something about what "the bug" is. You show 4 lines printing int(big_integer), but don't show any output. In addition, the patch *appears* to be against _Py_HashDouble (), but that function isn't involved in int() or in printing.

2. Please generate a context diff for patches, and attach the patch to the bug report instead of pasting it into the text box. SourceForge destroys the intended line structure and indentation in text boxes, and this non-context diff patch is very hard to follow in this mangled form.

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