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 mark.dickinson
Recipients alexandre.vassalotti, christian.heimes, donmez, gregory.p.smith, gvanrossum, loewis, mark.dickinson, matejcik, nnorwitz, pitrou, vstinner
Date 2009-05-13.20:05:38
SpamBayes Score 5.632565e-09
Marked as misclassified No
Message-id <1242245141.48.0.021861166145.issue1621@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2009-05-13 20:05:42mark.dickinsonsetrecipients: + mark.dickinson, gvanrossum, loewis, nnorwitz, gregory.p.smith, pitrou, vstinner, christian.heimes, alexandre.vassalotti, donmez, matejcik
2009-05-13 20:05:41mark.dickinsonsetmessageid: <1242245141.48.0.021861166145.issue1621@psf.upfronthosting.co.za>
2009-05-13 20:05:40mark.dickinsonlinkissue1621 messages
2009-05-13 20:05:38mark.dickinsoncreate