Message87704
Thanks Ismail. I'm currently using gcc-4.4 with the -ftrapv (not -fwrapv!) option to see how much breaks. (Answer: quite a lot. :-[ ) I'm finding many overflow checks that look like: size = Py_SIZE(a) * n; if (n && size / n != Py_SIZE(a)) { PyErr_SetString(PyExc_OverflowError, "repeated bytes are too long"); return NULL; } where size and n have type Py_ssize_t. That particular one comes from bytesobject.c (in py3k), but this style of check occurs frequently throughout the source. Do people think that all these should be fixed? The fix itself s reasonably straightforward: instead of multiplying and then checking for an overflow that's already happened (and hence has already invoked undefined behaviour according to the standards), get an upper bound for n *first* by dividing PY_SSIZE_T_MAX by Py_SIZE(a) and use that to do the overflow check *before* the multiplication. It shouldn't be less efficient: either way involves an integer division, a comparison, and a multiplication. The hard part is finding all the places that need to be fixed. | |
Date | User | Action | Args | 2009-05-13 20:05:42 | mark.dickinson | set | recipients: + mark.dickinson, gvanrossum, loewis, nnorwitz, gregory.p.smith, pitrou, vstinner, christian.heimes, alexandre.vassalotti, donmez, matejcik | 2009-05-13 20:05:41 | mark.dickinson | set | messageid: <1242245141.48.0.021861166145.issue1621@psf.upfronthosting.co.za> | 2009-05-13 20:05:40 | mark.dickinson | link | issue1621 messages | 2009-05-13 20:05:38 | mark.dickinson | create | | |