[Georg Brandl, on
http://python.org/sf/1523610 - PyArg_ParseTupleAndKeywords
potential core dump
]
> This one's almost fixed if we can decide what to do with "levels".
> I wrote some time ago:
>
> """
> With respect to this bug (which is about stack issues in Python/getargs.c
> involving misuse of the "levels" array), I think that we can drop the
> "levels" thing completely. It's only there to tell the user which exact item
> passed as part of a tuple argument cannot be accepted (and only if that
> function is implemented in C code). As tuple arguments
> are very rare "argument x" should be enough to tell the user that
> something's wrong with that tuple.
> """
More, the problem that remains is purely "a head bug": nobody ever
bumped into it, and the only way to provoke it is to write C (calling,
e.g., PyArg_ParseTupleAndKeywords) nesting tuple codes in an argument
descriptor string to an absurd depth. This is far from serious --
heck, it's far from even interesting <0.5 wink>.
I suggest closing this bug, getting it out of PEP 356, and opening a
new low-priority bug report against it. Fine by me if the `levels`
convolutions went away entirely, but at this stage in the 2.5 release
process I expect that's a bad idea: there is no /actual/ real-life
bug here, and getting rid of `levels` seems far more likely (because
of the amount of code touched) to introduce a new error than that
someone will nest tuple argument descriptors 32 deep. If someone's
actually afraid of that, fine, s/32/320/g in getargs.c instead :-)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
