Re: [Python-Dev] cpython: threading.RLock._acquire_restore() now raises a TypeError instead of a
02.01.14 13:54, victor.stinner написав(ла):
Please don't use "(...)" in PyArg_ParseTuple, it is dangerous (see issue6083 [1]). [1] http://bugs.python.org/issue6083
Hi, 2014/1/3 Serhiy Storchaka <storchaka@gmail.com>:
Oh, I didn't know this issue. Keeping a reference to the tuple is annoying, it adds a lot of cleanup code. Would it be possible to handle this issue in Argument Clinic, split the function in two parts: a function to parse arguments and keep references, and the implementation function? I already saw that when a format requires to keep a reference. See for example os_path() and os_path_impl() in Modules/posixmodule.c. Victor
2014/1/3 Victor Stinner <victor.stinner@gmail.com>:
Oh, I found a similiar issue but different issue:
This new function uses the following code to parse arguments: if (!PyArg_ParseTuple(args, _Py_PARSE_PID "i|(OO):prlimit", &pid, &resource, &curobj, &maxobj)) return NULL; "\u0100\u0101" is seen as a sequence. Getting an item of this sequence creates a new substring of 1 character, but the substring has only 1 reference, and the only reference is immediatly removed, so the borrowed reference (curobj and maxobj) become immediatly dangling pointers... Victor
Hi Serhiy, On Fri, Jan 3, 2014 at 8:59 AM, Serhiy Storchaka <storchaka@gmail.com> wrote:
+ if (!PyArg_ParseTuple(args, "(kl):_acquire_restore", &count, &owner))
Please don't use "(...)" in PyArg_ParseTuple, it is dangerous (see issue6083
I think that in this case it is fine, because the "k" and "l" are returning C integers. The refcounting issue occurs only when PyObject* are returned. A bientôt, Armin.
Hi, 2014/1/3 Serhiy Storchaka <storchaka@gmail.com>:
Oh, I didn't know this issue. Keeping a reference to the tuple is annoying, it adds a lot of cleanup code. Would it be possible to handle this issue in Argument Clinic, split the function in two parts: a function to parse arguments and keep references, and the implementation function? I already saw that when a format requires to keep a reference. See for example os_path() and os_path_impl() in Modules/posixmodule.c. Victor
2014/1/3 Victor Stinner <victor.stinner@gmail.com>:
Oh, I found a similiar issue but different issue:
This new function uses the following code to parse arguments: if (!PyArg_ParseTuple(args, _Py_PARSE_PID "i|(OO):prlimit", &pid, &resource, &curobj, &maxobj)) return NULL; "\u0100\u0101" is seen as a sequence. Getting an item of this sequence creates a new substring of 1 character, but the substring has only 1 reference, and the only reference is immediatly removed, so the borrowed reference (curobj and maxobj) become immediatly dangling pointers... Victor
Hi Serhiy, On Fri, Jan 3, 2014 at 8:59 AM, Serhiy Storchaka <storchaka@gmail.com> wrote:
+ if (!PyArg_ParseTuple(args, "(kl):_acquire_restore", &count, &owner))
Please don't use "(...)" in PyArg_ParseTuple, it is dangerous (see issue6083
I think that in this case it is fine, because the "k" and "l" are returning C integers. The refcounting issue occurs only when PyObject* are returned. A bientôt, Armin.
participants (3)
-
Armin Rigo -
Serhiy Storchaka -
Victor Stinner