Nadeem Vawda <nadeem.va...@gmail.com> added the comment: haypo> Can we just remove the test?
I think so. The test was originally intended to catch the case where crc32() or adler32() would get a buffer of >=4GB, and then silently truncate the size and produce an incorrect result (issue10276). However, 2.7's zlib doesn't define PY_SSIZE_T_CLEAN, so passing in a buffer of >=2GB raises an exception. So the condition that it was testing for can't happen in 2.7. sdaoden> Can we remove it? I would keep it, Apple is preparing the next sdaoden> major release (uname -a yet states 10.7.0 even though it's sdaoden> 10.6.7), and maybe then mmap() will fail for 0xDEADBEEF. sdaoden> Who will be the one which detects that otherwise?? I initially thought the same thing, but it turns out that the OS X sparsefile crash is also covered by LargeMmapTests.test_large_offset() in test_mmap. That test had also been failing sporadically before the F_FULLSYNC patch was committed (see issue11779). So keeping this test around would be redundant. sdaoden> Unfortunately we cannot test 0x80000000+ no more because sdaoden> Python prevents that such a buffer can be used - that's a shame. sdaoden> Maybe we could test 0x7FFFFFFF*2 aka 0xfffffffe in two iterations. That wouldn't accomplish the same thing. The point of the test is to pick up truncation issues that occur when you pass in a big buffer. These issues won't show up if you split the data up into smaller pieces. And in any case, they can't happen at all in 2.7, because the functions don't accept big buffers in the first place ;) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11277> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com