Message271759
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:14 | martin.panter | set | recipients:
+ 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:13 | martin.panter | set | messageid: <1470014773.69.0.35715884641.issue1621@psf.upfronthosting.co.za> |
2016-08-01 01:26:13 | martin.panter | link | issue1621 messages |
2016-08-01 01:26:12 | martin.panter | create | |
|