[issue34912] Update overflow checks in resize_buffer

Windson Yang added the comment: Sorry, Stefan Behnel, I still don't get it. alloc will always bigger than size after the if else case: if (size < alloc / 2) { /* Major downsize; resize down to exact size. */ alloc = size + 1; } else if (size < alloc) { /*

[issue34912] Update overflow checks in resize_buffer

STINNER Victor added the comment: The current code LGTM. -- nosy: +vstinner resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___

[issue34912] Update overflow checks in resize_buffer

Gregory P. Smith added the comment: correct, i don't see an obvious problem in the existing code. -- nosy: +gregory.p.smith ___ Python tracker ___

[issue34912] Update overflow checks in resize_buffer

Stefan Behnel added the comment: If I understand the code right, "PY_SSIZE_T_MAX/sizeof(Py_UCS4)" would not be correct since it would unnecessarily limit the length of ASCII-only unicode strings. I think the initial check avoids the risk of integer overflow in the calculations below, so

[issue34912] Update overflow checks in resize_buffer

Change by Terry J. Reedy : -- versions: -Python 3.4, Python 3.5 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue34912] Update overflow checks in resize_buffer

New submission from Windson Yang : In [resize_buffer](https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Modules/_io/stringio.c#L85) /* For simplicity, stay in the range of the signed type. Anyway, Python doesn't allow strings to be longer than this. */