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

[Victor Stinner]

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, to check crc32() and
adler32(). 0x7FFFFFFF is the biggest size supported by these functions
(zlib doesn't use Py_ssize_t in Python 2.7).

If you use a buffer of 0x80000000 bytes, you test PyArg_Parse*()
functions, which have already a dedicated test (in test_xml_etree_c,
it's not the best file to store such test...).

> Also, the assignment to m needs to be moved outside of the inner
> try...finally block.

Yeah, I noticed this with buildbots: already fixed by dd58f8072216.

> As an aside, in this sort of situation is it better to just go and
> commit a fix myself, or is raising it on the mailing list first the
> right way to do things?

I'm not sure that you understood the test, so I think that it's better
to ask first on IRC and/or the mailing list.

Victor