PyArg_ParseTuple problem with 'L' format

[theller]

BPO	723201
Nosy	@loewis, @theller
Files	getargs.patch: patch to getargs.c

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2005-03-03.12:29:07.000>
created_at = <Date 2003-04-17.16:03:41.000>
labels = ['interpreter-core']
title = "PyArg_ParseTuple problem with 'L' format"
updated_at = <Date 2005-03-03.12:29:07.000>
user = 'https://github.com/theller'

bugs.python.org fields:

activity = <Date 2005-03-03.12:29:07.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2003-04-17.16:03:41.000>
creator = 'theller'
dependencies = []
files = ['5192']
hgrepos = []
issue_num = 723201
keywords = ['patch']
message_count = 5.0
messages = ['43392', '43393', '43394', '43395', '43396']
nosy_count = 3.0
nosy_names = ['loewis', 'theller', 'mdehoon']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue723201'
versions = []

[theller]

PyArg_ParseTuple(tup, "B", &value) will raise 'Bad
Argument to internal function' if the object is not a
Python integer or long.
I believe the patch fixes the problem, but it is untested.

This problem probably exists since 2.2.

[mdehoon]

Logged In: YES
user_id=488897

I can replicate this bug with the "L" format but not with
"B". Is the 'B' in PyArg_ParseTuple(tup, "B",
&value) a typo?

[mdehoon]

Logged In: YES
user_id=488897

The PyLong_AsLongLong function (in Objects/longobject.c)
also contains a call to PyLong_Check and PyInt_Check, so I
would think that there is no need for another call to a
PyLong_Check and a PyInt_Check.
Instead, I would suggest to replace the
PyErr_BadInternalCall() (which raises the 'Bad Argument to
internal function') in PyLong_AsLongLong by

PyErr_SetString(PyExc_TypeError, "an integer is required").

This would also make it consistent with PyInt_AsLong in
Objects/intobject.c.

[loewis]

Logged In: YES
user_id=21627

I agree that the proposed double-type check is redundant.
OTOH, relying on the exception in the _As* function loses
information which argument specifically cannot be converted.
As a solution, I now clear the exception before invoking
converterr.

Fixed in
test_capi.py 1.8.2.1
NEWS 1.1193.2.24
getargs.c 2.102.2.1
test_capi.py 1.9
NEWS 1.1252
getargs.c 2.103

[loewis]

Logged In: YES
user_id=21627

Turns out that this approach breaks cases where
PyLong_AsLongLong returns OverflowErrors; it also turns out
that test_getargs2 is the place where the getargs tests are
implemented. So I reverted the previous patch, implemented
nb_int conversion for longs, and committed this as

test_capi.py 1.8.2.2
test_getargs2.py 1.5.12.1
longobject.c 1.165.2.1
getargs.c 2.102.2.2
test_capi.py 1.10
test_getargs2.py 1.6
longobject.c 1.166
getargs.c 2.104