[Python-Dev] [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by

[Victor Stinner]

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
> >> <python-checkins at python.org> 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