[docs] [issue23200] Clarify max_length and flush() for zlib decompression

Martin Panter report at bugs.python.org
Fri Jan 9 02:26:21 CET 2015


New submission from Martin Panter:

This simple patch documents that max_length has to be non-zero. The implementation actually uses zero as a special value to indicate max_length was not specified.

Also, I wonder what the point of the Decompressor.flush() method is. Reading the module code and zlib manual, it looks like it would return the same data as decompressor.decompress(decompressor.unconsumed_tail), except that it uses the Z_FINISH flag instead of Z_SYNC_FLUSH, so that zlib can optimize by assuming no more data is to be processed. Since unconsumed_tail is read-only and only relevant when using max_length, and flush does not support max_length, I wonder if the flush() method should be deprecated.

To further test this theory, I modified the test_zlib.py file so that all appropriate flush() calls are equivalent to this:

self.assertFalse(dco.flush())

and the tests all still pass.

BTW, it looks to me like zlib_Decompress_flush_impl() is setting avail_out too high (blessing unallocated memory) when the total length is more than half of UNIT_MAX, but I am not in a position to test this.

----------
assignee: docs at python
components: Documentation
files: max_length.patch
keywords: patch
messages: 233709
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: Clarify max_length and flush() for zlib decompression
versions: Python 3.4
Added file: http://bugs.python.org/file37650/max_length.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23200>
_______________________________________


More information about the docs mailing list