[issue9869] long_subtype_new segfault in pure-Python code

2010-09-26 Thread Mark Dickinson

Mark Dickinson dicki...@gmail.com added the comment:

 Right. In practice, returning a long instead of an int can produce bugs,
 mainly because some C functions will only accept ints and refuse longs.

I'd say 'in theory' rather than 'in practice' here.  In this particular case, I 
don't see much danger:  any C code explicitly calling PyNumber_Long (rather 
than PyNumber_Int) surely has to be prepared to deal with a long, since that's 
what's going to be returned in the vast majority of cases.  Similarly for 
Python code calling 'long' rather than 'int'.

I'd also note that the docs state clearly that PyNumber_Long returns a long 
(while PyNumber_Int, in contrast, is permitted to return either an int or a 
long);  similarly for the builtin 'long' function.

And finally, looking at the history of the test_class test (see issue 1671298), 
it doesn't look as if anyone was thinking too hard about return types at that 
point---it looks like the test was just fit to the existing semi-broken 
behaviour.

So I'm still proposing to apply this patch, in spite of Antoine's -1. ;-)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9869
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9869] long_subtype_new segfault in pure-Python code

2010-09-26 Thread Mark Dickinson

Mark Dickinson dicki...@gmail.com added the comment:

Committed in r85016.  I'll take responsibility for any broken 3rd party code...

--
resolution:  - fixed
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9869
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9869] long_subtype_new segfault in pure-Python code

2010-09-18 Thread Mark Dickinson

Mark Dickinson dicki...@gmail.com added the comment:

Problem confirmed here; thanks for the report.

I think it's also a bug that after:

class A(object):
def __long__(self):
return 42

long(A()) returns an object of type 'int' rather than an object of type 'long'. 
 It's inconsistent with what happens with __trunc__, too:

 class A(object):
... def __trunc__(self): return 42
... 
[37198 refs]
 long(A())
42L
[37201 refs]

What's a little bit odd is that there's a test for the __long__-returning-int 
behaviour in test_class that asserts the return type should be int.

Here's a patch that fixes the return type of long (and PyNumber_Long) to be 
long in these cases.

--
keywords: +patch
Added file: http://bugs.python.org/file18918/issue9869.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9869
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9869] long_subtype_new segfault in pure-Python code

2010-09-18 Thread Mark Dickinson

Mark Dickinson dicki...@gmail.com added the comment:

Removing 2.6 from the versions, since this isn't a security problem (as far as 
I know).

--
versions:  -Python 2.6

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9869
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com




[issue9869] long_subtype_new segfault in pure-Python code

2010-09-18 Thread Antoine Pitrou

Antoine Pitrou pit...@free.fr added the comment:

 What's a little bit odd is that there's a test for the __long__-
 returning-int behaviour in test_class that asserts the return type
 should be int.

If there is a test then the behaviour is probably deliberate, and changing it 
would break compatibility.

--
nosy: +pitrou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9869
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9869] long_subtype_new segfault in pure-Python code

2010-09-18 Thread Eric Smith

Eric Smith e...@trueblade.com added the comment:

There are plenty of tests that check implementation specific internal 
behaviors. I don't think the presence of test alone would mean that it can't be 
changed.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9869
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9869] long_subtype_new segfault in pure-Python code

2010-09-18 Thread Antoine Pitrou

Antoine Pitrou pit...@free.fr added the comment:

 There are plenty of tests that check implementation specific internal
 behaviors. I don't think the presence of test alone would mean that it
 can't be changed.

Right. In practice, returning a long instead of an int can produce bugs,
mainly because some C functions will only accept ints and refuse longs.

(which is the C functions' fault, but unless you want to find and fix
all of them (including perhaps in 3rd-party libraries), I think it's
better not to change the current behaviour)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9869
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9869] long_subtype_new segfault in pure-Python code

2010-09-16 Thread Carl Witty

New submission from Carl Witty carl.wi...@gmail.com:

PyNumber_Long() (and hence long_new()) are willing to return ints, rather than 
longs.  However, when long_subtype_new() calls long_new(), it casts the result 
to PyLongObject* without a check.  (Well, there is an assertion, so if 
assertions are enabled you'd get an assertion failure instead of a potential 
segmentation fault.)

The attached program segfaults for me; returning smaller numbers than 100 
sometimes gives bad answers instead of crashing.

--
components: Interpreter Core
files: python_long_bug.py
messages: 116514
nosy: cwitty
priority: normal
severity: normal
status: open
title: long_subtype_new segfault in pure-Python code
type: crash
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file18899/python_long_bug.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9869
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9869] long_subtype_new segfault in pure-Python code

2010-09-16 Thread Mark Dickinson

Changes by Mark Dickinson dicki...@gmail.com:


--
assignee:  - mark.dickinson
nosy: +mark.dickinson
priority: normal - high

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9869
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9869] long_subtype_new segfault in pure-Python code

2010-09-16 Thread Eric Smith

Changes by Eric Smith e...@trueblade.com:


--
nosy: +eric.smith
versions:  -Python 2.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9869
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com