[issue9869] long_subtype_new segfault in pure-Python code

Mark Dickinson added the comment: Committed in r85016. I'll take responsibility for any broken 3rd party code... -- resolution: -> fixed status: open -> closed ___ Python tracker _

[issue9869] long_subtype_new segfault in pure-Python code

Mark Dickinson 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 c

[issue9869] long_subtype_new segfault in pure-Python code

Antoine Pitrou 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 f

[issue9869] long_subtype_new segfault in pure-Python code

Eric Smith 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 _

[issue9869] long_subtype_new segfault in pure-Python code

Antoine Pitrou 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. -

[issue9869] long_subtype_new segfault in pure-Python code

Mark Dickinson 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 ___ __

[issue9869] long_subtype_new segfault in pure-Python code

Mark Dickinson 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

[issue9869] long_subtype_new segfault in pure-Python code

Changes by Eric Smith : -- nosy: +eric.smith versions: -Python 2.5 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue9869] long_subtype_new segfault in pure-Python code

Changes by Mark Dickinson : -- assignee: -> mark.dickinson nosy: +mark.dickinson priority: normal -> high ___ Python tracker ___ ___ P

[issue9869] long_subtype_new segfault in pure-Python code

New submission from Carl Witty : 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