René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Specialized list subscript/store can mishandle non-compact int indices","articleBody":"### Bug description:\n\nThe specialized list/int subscript and store paths can be entered after a code object was specialized with a compact non-negative int index, then later called with a non-compact exact int index.\n\nAt specialization time, `BINARY_OP_SUBSCR_LIST_INT` and `STORE_SUBSCR_LIST_INT` require `_PyLong_IsNonNegativeCompact(sub)`, but the runtime macro only guards with `_GUARD_TOS_INT`. The specialized operation then calls `_PyLong_CompactValue()` without rechecking compactness.\n\nOn debug builds this can trip the `_PyLong_CompactValue()` assertion. On release builds, a non-compact value whose low digit is zero, such as `1 \u003c\u003c 64`, can be treated as index `0` rather than falling back to generic list indexing and raising `IndexError`.\n\nMinimal CPython-internal reproducer:\n\n```python\nimport dis\nimport _testinternalcapi\n\ndef get(index):\n    a = [1, 2, 3]\n    return a[index]\n\nfor _ in range(_testinternalcapi.SPECIALIZATION_THRESHOLD):\n    assert get(0) == 1\n\nassert \"BINARY_OP_SUBSCR_LIST_INT\" in {\n    instruction.opname for instruction in dis.get_instructions(get, adaptive=True)\n}\nget(1 \u003c\u003c 64)\n```\n\nThe same invariant issue applies to `STORE_SUBSCR_LIST_INT` after warming with index `0` and then storing with `1 \u003c\u003c 64`.\n\n### CPython versions tested on:\n\nCPython main branch\n\n### Operating systems tested on:\n\nmacOS\n\n\u003c!-- gh-linked-prs -->\n### Linked PRs\n* gh-153004\n\u003c!-- /gh-linked-prs -->\n","author":{"url":"https://github.com/KRRT7","@type":"Person","name":"KRRT7"},"datePublished":"2026-07-04T07:22:45Z","url":"https://github.com/python/cpython/issues/153002"}