| msg13728 - (view) |
Author: Neil Schemenauer (nascheme) *  |
Date: 2002-12-30 20:29 |
| 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__. |
|
|
| msg13729 - (view) |
Author: Neil Schemenauer (nascheme) * |
Date: 2003-01-16 21:33 |
| 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 "", 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. |
|
|
| msg13730 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2003-01-16 21:57 |
| 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. |
|
|
| msg13731 - (view) |
Author: Neil Schemenauer (nascheme) * |
Date: 2003-01-16 23:10 |
| 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. |
|
|
| msg13732 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2003-01-17 00:19 |
| Logged In: YES user_id=6380 Yes, this should go into 2.3a2. Your attachment upload failed somehow. |
|
|
| msg13733 - (view) |
Author: Neil Schemenauer (nascheme) * |
Date: 2003-01-19 19:35 |
| 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'). |
|
|
| msg13734 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2003-01-21 19:55 |
| Logged In: YES user_id=6380 Looks like a good patch. And yes, the other types should be doing this as well. |
|
|
| msg13735 - (view) |
Author: Neil Schemenauer (nascheme) * |
Date: 2003-01-24 22:20 |
| Logged In: YES user_id=35752 I added the check for the other integer codes. All the tests pass so I checked it in. Hope that's okay. |
|
|
| msg13736 - (view) |
Author: Jack Jansen (jackjansen) * |
Date: 2003-01-26 21:58 |
| Logged In: YES user_id=45365 Neil, your mod to PyArg_Parse is far too aggressive. Apparently the integer formats have accepted floating point arguments since day one, and all weekend I'm running across places where floats are passed to integers. For example, the MacPython IDE does this all the time, and I wouldn't be surprised if there's lots of windowing code that does this (compute pixel positions in floating point and then passing them to something expecting an integer). If this is fixed in this way (disallowing floats where integers are expected) it should at least be done with a DeprecationWarning for one release cycle. I think the fix probably is a good idea in the long run, but it will break large bodies of code... |
|
|
| msg13737 - (view) |
Author: Neil Schemenauer (nascheme) * |
Date: 2003-01-27 05:57 |
| Logged In: YES user_id=35752 Attached is a patch that signals a DepreciationWarning instead of rasing a TypeError. I used a static function to avoid duplication of code. My version of GCC inlines it. |
|
|
| msg13738 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2003-02-03 22:15 |
| Logged In: YES user_id=6380 Loosk good -- please check it in. Probably requires something in NEWS too. |
|
|
| msg13739 - (view) |
Author: Neil Schemenauer (nascheme) * |
Date: 2003-02-04 21:02 |
| Logged In: YES user_id=35752 Checked in as getargs.c 2.96 with NEWS. |
|
|