Kristján Valur Jónsson <[email protected]> added the comment:
On the other hand, Antoine is correct in that we _could_ use the existing
infrastructure and count PyIter_Next() as a recursion in the same way as
entering the ceval loop is a recursion. Extra checking in there would hardly
slow down the execution much. (but it would have to do its job only when
invoking a "c" implemented iternext routine...)
I tried to come up with other ways that we could create deeply nested C
function calls...
Here's one:
...
a = (a, a)
b = (b, b)
a < b
This however gets caught by this code:
if (Py_EnterRecursiveCall(" in comparison"))
return NULL;
res = do_richcompare(v, w, op);
Py_LeaveRecursiveCall();
So obviously someone thought this could be an issue.
However:
...
a = {1: a}
repr(a)
will generate the same crash. (tuple repr and list repr have guards, dict repr
not)
So, there are various ways to get c recursion to overflow the C stack. Some of
them have been patched throughout the years, others not.
We could try to identify all the different ways. We could for example add
guards in PyObject_Repr() rather than individual types. But I'm sure we will
leave holes in place like the OP discovered with deeply nested iterators.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue14507>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
