gh-135177: Raise OverflowError in _Py_call_instrumentation_jump to handle potential integer overflow #135202
Conversation
… to handle potential integer overflow
Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
Clarified that we are referring to the int type in C. Co-authored-by: Victor Stinner <vstinner@python.org>
…ential overflow Co-authored-by: Victor Stinner <vstinner@python.org>
|
@skirpichev @ZeroIntensity: So what do you think? Is it worth it to fix this issue? Are you ok with Py_ssize_t and an assertion? |
to <= INT_MAX / (int)sizeof(_Py_CODEUNIT) seems broken in tests
… to Py_ssize_t for type consistency in assert Co-authored-by: Victor Stinner <vstinner@python.org>
|
Yeah, an assertion makes more sense to me. I'm pretty sure it would take several years for Python to compile code that actually triggers the assertion. |
It's definitely worth, as it seems that assumptions for the current code - broken in CI tests. With replacement to Py_ssize_t (for |
|
There is no risk of overflow. The bytecode compiler ensures that the size of the code is within bounds for a 32 bit int. |
Do you suggest to close the PR? |
This pull request adds a runtime check to handle potential integer overflow in the _Py_call_instrumentation_jump function.