[issue10276] zlib crc32/adler32 buffer length truncation (64-bit)

2016-05-26 Thread Martin Panter
Changes by Martin Panter : -- Removed message: http://bugs.python.org/msg135065 ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue10276] zlib crc32/adler32 buffer length truncation (64-bit)

2016-05-26 Thread Martin Panter
Changes by Martin Panter : -- Removed message: http://bugs.python.org/msg135066 ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue10276] zlib crc32/adler32 buffer length truncation (64-bit)

2011-05-03 Thread Nadeem Vawda
Nadeem Vawda added the comment: Changeset a0681e7a6ded fixes this bug for 2.7 - too-large buffers cause an OverflowError during argument parsing, so there is no possibility of truncation happening. -- status: open -> closed ___ Python tracker

[issue10276] zlib crc32/adler32 buffer length truncation (64-bit)

2011-05-03 Thread Steffen Daode Nurpmeso
Steffen Daode Nurpmeso added the comment: Ha! I always knew it! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue10276] zlib crc32/adler32 buffer length truncation (64-bit)

2011-05-03 Thread Roundup Robot
Roundup Robot added the comment: New changeset dd58f8072216 by Victor Stinner in branch '2.7': Issue #10276: Fix test_zlib, m may be undefined in the finally block http://hg.python.org/cpython/rev/dd58f8072216 -- ___ Python tracker

[issue10276] zlib crc32/adler32 buffer length truncation (64-bit)

2011-05-03 Thread Roundup Robot
Roundup Robot added the comment: New changeset f43213129ba8 by Victor Stinner in branch '2.7': Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by http://hg.python.org/cpython/rev/f43213129ba8 -- nosy: +python-dev status: pending -> open

[issue10276] zlib crc32/adler32 buffer length truncation (64-bit)

2011-02-21 Thread Antoine Pitrou
Antoine Pitrou added the comment: Thank you for the patch! Committed in r88460 (3.3) and r88461 (3.2). 2.7 would need more surgery in order for this to be fixed, see #8651 and #8650. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> pending versions: -P

[issue10276] zlib crc32/adler32 buffer length truncation (64-bit)

2011-02-21 Thread Antoine Pitrou
Antoine Pitrou added the comment: Patch looks good to me. -- nosy: +pitrou stage: -> patch review versions: +Python 3.3 -Python 3.1 ___ Python tracker ___ _

[issue10276] zlib crc32/adler32 buffer length truncation (64-bit)

2011-01-26 Thread Nadeem Vawda
Nadeem Vawda added the comment: Here is an update patch, which corrects a typo in the previous patch, and adds a test to test_zlib. The test uses a memory-mapped sparse file, so it gets skipped on systems without mmap. The alternative would be to allocate a 4+GB buffer of ordinary memory, ca

[issue10276] zlib crc32/adler32 buffer length truncation (64-bit)

2010-11-01 Thread Éric Araujo
Changes by Éric Araujo : -- components: +Extension Modules -Library (Lib) versions: -Python 2.5, Python 2.6, Python 3.3 ___ Python tracker ___ __

[issue10276] zlib crc32/adler32 buffer length truncation (64-bit)

2010-11-01 Thread Martin v . Löwis
Martin v. Löwis added the comment: I find your approach fine; there isn't a need (IMO) to have the underlying functions change. -- nosy: +loewis ___ Python tracker ___

[issue10276] zlib crc32/adler32 buffer length truncation (64-bit)

2010-11-01 Thread Nadeem Vawda
New submission from Nadeem Vawda : zlib.crc32() and zlib.adler32() in Modules/zlibmodule.c don't handle buffers of >=4GB correctly. The length of a Py_buffer is of type Py_ssize_t, while the C zlib functions take length as an unsigned integer. This means that on a 64-bit build, the buffer leng