[Python-bugs-list] [ python-Bugs-676155 ] RuntimeWarning with tp_compare

[SourceForge.net]

Bugs item #676155, was opened at 2003-01-28 10:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Neal Norwitz (nnorwitz)
Summary: RuntimeWarning with tp_compare

Initial Comment:
>From the latest CVS, as of the morning of Jan. 28 2003

>>> s = "12345" * 1000
>>> float(s) == int(s)
__main__:1: RuntimeWarning: tp_compare didn't return -1
or -2 for exception
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: long int too large to convert to float
>>>



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

>Comment By: Tim Peters (tim_one)
Date: 2003-01-28 14:21

Message:
Logged In: YES 
user_id=31435

nb_coerce is called from only a couple places in the core, 
and they're happy with a -1 return.  Note that complex_coerce 
can already return -1 (and for the same reason:  long->double 
overflow).  It's a general rule than every number-returning C 
API function returns -1 to indicate error.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-28 13:43

Message:
Logged In: YES 
user_id=33168

Returning -1 from float_coerce() fixes the original problem of 
comparing float(s) == int(s) as well as the coerce()
problem.  Is that correct though?  It seems all other
nb_coerce's return only 0 or 1.  Might returning -1 create
other problems?

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

Comment By: Michael Hudson (mwh)
Date: 2003-01-28 13:10

Message:
Logged In: YES 
user_id=6656

Here's a guess.  Caveat emptor & all.

The thing is, returning 1 from a nb_coerce means "I can't do
it", not "I tried and there was an exception", so presumably
whatever code is calling it just goes off and calls the
other types nb_coerce method.  So I think your patch needs
to return -1.

But then the other type never gets a chance to see the
objects.  IOW, this is a crock.

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

Comment By: Tim Peters (tim_one)
Date: 2003-01-28 12:47

Message:
Logged In: YES 
user_id=31435

The patch definitely fixes a bug, and maybe even this bug 
<iwnk>.

At one time, nobody ever checked PyLong_AsDouble for an 
error return, and at that time I checked & repaired all call 
sites in the core.  Added this NEWS blurb at the time:

"""
Note that PyLong_AsDouble can fail!  This has always been
true, but no callers checked for it.  It's more likely to fail now,
because overflow errors are properly detected now.  The
proper way to check::

double x = PyLong_AsDouble(some_long_object);
if (x == -1.0 && PyErr_Occurred()) {
              /* The conversion failed. */
}
"""

Maybe I missed this one then, or maybe it's newer code.  
Whatever, +1 on fixing it.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-28 12:41

Message:
Logged In: YES 
user_id=33168

Let me try that again, this time without confusing the
issues.  Sorry about that.

The patch does fix the coerce problem I mentioned.

The patch also fixes the bug report problem in that now an
OverflowError is raised.  However, even with the patch I get
the undetected error:

>>> float(s) == int(s)
False
XXX undetected error
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: long int too large to convert to float

I'll keep working on the problem.  Should be pretty shallow
now, I hope.

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

Comment By: Michael Hudson (mwh)
Date: 2003-01-28 12:33

Message:
Logged In: YES 
user_id=6656

That looks like the fix to me.

Presumably you meant "*without* this patch I get..."?

I suggest you check it in.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-28 12:23

Message:
Logged In: YES 
user_id=33168

I thought I fixed the problem in one place (patch attached).
 That fixes this problem:

 coerce(0.5, int(s))

With this patch, I get:
XXX undetected error (why=3)


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

Comment By: Michael Hudson (mwh)
Date: 2003-01-28 12:15

Message:
Logged In: YES 
user_id=6656

Hmm, wierd.  I think there may be a case of something
setting an exception and then not returning NULL (or
whatever).  You can certainly get some wierd tracebacks.

Buggered if I know where though -- "you are in a maze of
twisty function calls, all alike" :-/

Some playing with a debug build and gdb coming up...

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

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