Serhiy Storchaka added the comment:
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.
--
resolution: - fixed
stage: - committed/rejected
status: open -
Serhiy Storchaka added the comment:
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,
Changes by Serhiy Storchaka storch...@gmail.com:
--
assignee: - serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16096
___
___
Changes by Mark Dickinson dicki...@gmail.com:
--
assignee: mark.dickinson -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16096
___
___
Mark Dickinson added the comment:
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
Changes by Mark Dickinson dicki...@gmail.com:
--
versions: -Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16096
___
___
Mark Dickinson added the comment:
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
Serhiy Storchaka added the comment:
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.
--
___
Python tracker rep...@bugs.python.org
Mark Dickinson added the comment:
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
Serhiy Storchaka added the comment:
unless they can be shown to cause actual bugs.
See issue14700.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16096
___
Mark Dickinson added the comment:
Serhiy, I don't understand what you're getting at. Can you explain?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16096
___
Roundup Robot added the comment:
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
Mark Dickinson added the comment:
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
Mark Dickinson added the comment:
Whoops. I take it back about the Objects/longobject.c bit. Fixing ...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16096
___
Roundup Robot added the comment:
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':
Serhiy Storchaka added the comment:
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?
--
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16096
___
Andrew Svetlov added the comment:
The patches looks good for me, but I like to double check before commit.
Let's wait for a week for other reviewers.
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16096
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16096
___
___
Python-bugs-list
STINNER Victor added the comment:
It's maybe safer (and simpler) to not touch such code in Python older than 3.4.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16096
___
New submission from Serhiy Storchaka:
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
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file27361/size_overflow-3.2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16096
___
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file27362/size_overflow-2.7.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16096
___
23 matches
Mail list logo
