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 ztane
Recipients Decorater, martin.panter, serhiy.storchaka, xiang.zhang, ztane
Date 2016-07-14.10:41:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1468492874.54.0.436292303205.issue27507@psf.upfronthosting.co.za>
In-reply-to
Content
if (len == PY_SSIZE_T_MAX) is necessary for the case that the iterable is already PY_SSIZE_T_MAX items. However it could be moved inside the *other* if because if (len == PY_SSIZE_T_MAX) should also fail the overflow check.

However, I believe it is theoretical at most with stuff that Python supports that it would even be possible to allocate an array of PY_SSIZE_T_MAX *pointers*. The reason is that the maximum size of object can be only that of `size_t`, and Py_ssize_t should be a signed type of that size; and it would thus be possible only to allocate an array of PY_SSIZE_T_MAX pointers only if they're 16 bits wide.

In any case, this would be another place where my proposed macro "SUM_OVERFLOWS_PY_SSIZE_T" or something would be in order to make it read

    if (SUM_OVERFLOWS_PY_SSIZE_T(len, (len >> 1) + 1)

which would make it easier to spot mistakes in the sign preceding 1.
History
Date User Action Args
2016-07-14 10:41:14ztanesetrecipients: + ztane, martin.panter, serhiy.storchaka, xiang.zhang, Decorater
2016-07-14 10:41:14ztanesetmessageid: <1468492874.54.0.436292303205.issue27507@psf.upfronthosting.co.za>
2016-07-14 10:41:14ztanelinkissue27507 messages
2016-07-14 10:41:14ztanecreate