Le mercredi 04 mai 2011 à 15:40 -0700, Ethan Furman a écrit :
Victor Stinner wrote:
Le mardi 03 mai 2011 à 16:22 +0200, Nadeem Vawda a écrit :
On Tue, May 3, 2011 at 3:19 PM, victor.stinner
wrote: +# Issue #10276 - check that inputs of 2 GB are handled correctly. +# Be aware of issues #1202, #8650, #8651 and #10276 +class ChecksumBigBufferTestCase(unittest.TestCase): + int_max = 0x7FFFFFFF + + @unittest.skipUnless(mmap, "mmap() is not available.") + def test_big_buffer(self): + if sys.platform[:3] == 'win' or sys.platform == 'darwin': + requires('largefile', + 'test requires %s bytes and a long time to run' % + str(self.int_max)) + try: + with open(TESTFN, "wb+") as f: + f.seek(self.int_max-4) + f.write("asdf") + f.flush() + try: + m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) + self.assertEqual(zlib.crc32(m), 0x709418e7) + self.assertEqual(zlib.adler32(m), -2072837729) + finally: + m.close() + except (IOError, OverflowError): + raise unittest.SkipTest("filesystem doesn't have largefile support") + finally: + unlink(TESTFN) + + 0x7FFFFFFF is (2G-1) bytes. For a 2GB buffer, int_max should be 0x80000000. However, if you make this change, crc32() and adler32() raise OverflowErrors (see changeset a0681e7a6ded).
I don't want to check OverflowError: the test is supposed to compute the checksum of a buffer of 0x7FFFFFFF bytes
The comment says 'check that inputs of 2 GB are handled correctly' but the file created is 1 byte short of 2Gb. Is the test wrong, or just wrongly commented? Or am I not understanding?
If you write a byte after 2 GB of zeros, the file size is 2 GB+the few bytes. This trick is to create quickly a large file: some OSes support sparse files, zeros are not written on disk. But on Mac OS X and Windows, you really write 2 GB+some bytes. Victor