Mark Dickinson <dicki...@gmail.com> added the comment:
A few comments:
(1) I agree that signed overflows should be avoided
where possible.
(2) I think some of the changes in the latest patch
(fix-overflows-final.patch) are unnecessary, and
decrease readability a bit. An example is the following
chunk for the x_divrem function in Objects/longobject.c.
@@ -1799,7 +1799,7 @@ x_divrem(PyLongObject *v1, PyLongObject *w1, PyLongObject
**prem)
k = size_v - size_w;
a = _PyLong_New(k + 1);
- for (j = size_v; a != NULL && k >= 0; --j, --k) {
+ for (j = size_v; a != NULL && k >= 0; j = (unsigned)j - 1 , k =
(unsigned)k - 1) {
digit vj = (j >= size_v) ? 0 : v->ob_digit[j];
twodigits q;
stwodigits carry = 0;
In this case it's easy to see from the code that j and k
will always be nonnegative, so replacing --j with j =
(unsigned)j - 1 is unnecessary. (This chunk no longer
applies for 2.7 and 3.1, btw, since x_divrem got
rewritten recently.) Similar comments apply to the
change:
- min_gallop -= min_gallop > 1;
+ if (min_gallop > 1) min_gallop = (unsigned)min_gallop -
1;
in Objects/listobject.c. Here it's even clearer that
the cast is unnecessary.
I assume these changes were made to silence warnings from
-Wstrict-overflow, but I don't think that should be a goal:
I'd suggest only making changes where there's a genuine
possibility of overflow (even if it's a remote one), and
leaving the code unchanged if it's reasonably easy to
see that overflow is impossible.
(3) unicode_hash also needs fixing, as do the lookup
algorithms for set and dict. Both use overflowing
arithmetic on signed types as a matter of course.
Probably a good few of the hash algorithms for the
various object types in Objects/ are suspect.
----------
nosy: +marketdickinson
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
