In several places such dungerous code used to check the integer overflow:

  size = n * itemsize;
  if (size / itemsize != n) raise exception...

Because these values are signed, this results in undefined behavior.

The proposed patches replace similar unsafe code to safe one. Note that the patches for the different versions are substantially different.

The patches looks good for me, but I like to double check before commit.
Let's wait for a week for other reviewers.

It's maybe safer (and simpler) to not touch such code in Python older than 3.4.

> It's maybe safer (and simpler) to not touch such code in Python
> older than 3.4.

So far, I've been fixing these overflow bugs only in the development branches, unless they can be shown to cause actual bugs.  That said, I think it's probably okay to apply these for 3.3 as well as 3.4, especially since the 3.3 patch is smaller than the others.  I'll review and apply.

> especially since the 3.3 patch is smaller than the others.

It's becouse 3.3 already contains some fixes which was not be backported to 
older versions.

> It's becouse 3.3 already contains some fixes which was not be backported
> to older versions.

Yes, exactly!  That's what I meant when I said:

"So far, I've been fixing these overflow bugs only in the development branches"

There were lots of integer overflow occurrences like these found by John Regehr in issue 9530.  I chose to fix those only in the current development branch, which was 3.3 at the time.  Since we've made an effort to clean up 3.3 in that respect, I think it's worth finishing that job off by applying your patch both to 3.3 and 3.4.

> unless they can be shown to cause actual bugs.

See issue14700.

Serhiy, I don't understand what you're getting at.  Can you explain?

New changeset 152d85b2da3a by Mark Dickinson in branch '3.3':
Issue #16096: Fix several occurrences of potential signed integer overflow.  Thanks Serhiy Storchaka.
http://hg.python.org/cpython/rev/152d85b2da3a

New changeset faae99459b43 by Mark Dickinson in branch 'default':
Issue #16096: Merge fixes from 3.3.
http://hg.python.org/cpython/rev/faae99459b43

Applied the 3.3 patch to 3.3 and default, with some minor changes:

 - revert the Objects/longobject.c changes, since they don't depend
   on signed overflow

 - fix the second change in Objects/tupleobject.c so that the overflow check happens before the multiplication rather than after.

Whoops.  I take it back about the Objects/longobject.c bit.  Fixing ...

New changeset 906ae6485cb8 by Mark Dickinson in branch '3.3':
Issue #16096: Fix signed overflow in Objects/longobject.c.  Thanks Serhiy Storchaka.
http://hg.python.org/cpython/rev/906ae6485cb8

New changeset b728aac3bdb3 by Mark Dickinson in branch 'default':
Issue #16096: port fix from 3.3
http://hg.python.org/cpython/rev/b728aac3bdb3

In issue14700 were fixed two actual bugs. The fix was not be backported to older 
versions (and this changes included in patches for this issue). I think it is 
better to reopen issue14700 for backporting fixes to 2.7 and 3.2?

Yes, reopening issue 14700 sounds good to me.

I'm not against fixing these issues in the bugfix branches, but we need to do it carefully (which unfortunately probably also means slowly).  I think that for the bugfix branches, each fix should be accompanied by a test that exercises the original bug.  I'd also suggest having a separate issue for each bug, for ease of review.

I'd probably also prioritise those bugs that can be triggered without having huge structures in memory:  e.g., the issue 14700 bug seems more important to fix than the PyTuple_New bug.

Here are updated to current codebase patches for 2.7 and 3.2. It seems that 
all the rest of overflows are hypothetical bugs and do not appear on the 
current supported platforms. Fix them is not necessary (rather for purity). If 
no one can see visible bugs, I'll close this issue soon.

I withdraw my patches for 2.7 and 3.2 due to the fact that they have no visible effect on supported platforms. Patches for 3.3+ already committed, therefore I close this issue.