[Python-bugs-list] [ python-Bugs-660144 ] typeobject provides incorrect __mul__

[SourceForge.net]

Bugs item #660144, was opened at 2002-12-30 20:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Guido van Rossum (gvanrossum)
Summary: typeobject provides incorrect __mul__

Initial Comment:
type __mul__ is wierd:

>> 'a'.__mul__(3.4)
'aaa'
>>> [1].__mul__(3.4)
[1, 1, 1]

Floating point numbers with fractions should not be
accepted.
I think the problem is that __mul__ should not be trying to
implement sq_repeat behavior (although I haven't dug
deeply into this problem yet).  Also, I think the code is
vulnerable to integer overflow.

Should also check __imul__ __add__ __iadd__.

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

>Comment By: Neil Schemenauer (nascheme)
Date: 2003-01-19 19:35

Message:
Logged In: YES 
user_id=35752

The small patch is attached.  I only added the checking for
'i' and 'l'.  I wonder if it should be done for the other
integer codes as well (e.g. 'b', 'h').

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-17 00:19

Message:
Logged In: YES 
user_id=6380

Yes, this should go into 2.3a2.

Your attachment upload failed somehow.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2003-01-16 23:10

Message:
Logged In: YES 
user_id=35752

Would this be a change for the 2.3 release?  I tried adding
a PyFloat_Check
test to 'i' and 'l' in getargs.c.  It looks like all the
unit tests pass.  I agree that
checking for float catches the important cases.



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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-16 21:57

Message:
Logged In: YES 
user_id=6380

This is an age-old problem that crops up whenever "i" and
similar format codes are used.

The problem is that on the one hand you want "i" to accept
other int-ish types that have an __int__ method. But on the
other hand you don't want it to accept float, which also has
an __int__ method. Or other float-ish types.

I think the "i" format code has to be fixe, but I'm not sure
how -- maybe as a start it would be sufficient to test
explicitly for float and its subclasses and reject those.
That would still allow 3rd party float-ish classes that
implement __int__, but that's not so important.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2003-01-16 21:33

Message:
Logged In: YES 
user_id=35752

I think the problem is that wrap_intargfunc and
wrap_intintargfunc use PyArg_ParseTuple(args, "i", &i). 
This bug also is present in methods like __getitem__:

>>> "Python"[1.2]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: sequence index must be integer
>>> "Python".__getitem__(1.2)
'y'

I think the right fix is to use explictly only allow only
ints and longs to wrap_intargfunc and friends.  If Guido
agrees I will cook up a patch.  It seems like we should have
a code for PyParse_Tuple that only allows ints and longs.

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

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