This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients Jeffrey.Walton, alex, alexandre.vassalotti, christian.heimes, deadshort, dmalcolm, donmez, fweimer, gregory.p.smith, jcea, jwilk, loewis, mark.dickinson, martin.panter, matejcik, nnorwitz, pitrou, python-dev, serhiy.storchaka, vstinner, xiang.zhang, ztane
Date 2016-08-01.01:26:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
overflow_fix_in_listextend.patch: I doubt Python supports the kinds of platform where this overflow would be possible. It may require pointers smaller than 32 bits, or char objects larger than 8 bits. Perhaps we could just add a comment explaining we assume the overflow cannot happen.

It seems list objects will hold one pointer for each element, but the overflow involves the number of elements. Python defines PY_SSIZE_T_MAX as PY_SIZE_MAX // 2. For the overflow to happen we would need

m + n > PY_SSIZE_T_MAX

Assuming a “flat” address space that can allocate up to PY_SIZE_MAX bytes _in total_, the total number of elements cannot exceed

m + n == PY_SIZE_MAX // sizeof (PyObject *)

So in this scenario, the overflow cannot happen unless sizeof (PyObject *) == 1.

Considering things like the 16-bit segmented Intel “large” memory model (which I doubt Python is compatible with), each list could _independently_ be up to PY_SIZE_MAX bytes. Therefore the total number of elements may reach

m + n == PY_SIZE_MAX // sizeof (PyObject *) * 2

So even in this case, sizeof (PyObject *) == 4 (large model) is fine, but anything less (e.g. 16-bit char, or 1-byte segment + 2-byte offset) might overflow.
Date User Action Args
2016-08-01 01:26:14martin.pantersetrecipients: + martin.panter, loewis, nnorwitz, gregory.p.smith, jcea, mark.dickinson, pitrou, vstinner, christian.heimes, alexandre.vassalotti, donmez, matejcik, jwilk, alex, dmalcolm, python-dev, deadshort, serhiy.storchaka, ztane, fweimer, Jeffrey.Walton, xiang.zhang
2016-08-01 01:26:13martin.pantersetmessageid: <>
2016-08-01 01:26:13martin.panterlinkissue1621 messages
2016-08-01 01:26:12martin.pantercreate