Message233709
| Author |
martin.panter |
| Recipients |
docs@python, martin.panter |
| Date |
2015年01月09日.01:26:18 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2015年01月09日 01:26:21 | martin.panter | set | recipients:
+ martin.panter, docs@python |
| 2015年01月09日 01:26:21 | martin.panter | set | messageid: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za> |
| 2015年01月09日 01:26:21 | martin.panter | link | issue23200 messages |
| 2015年01月09日 01:26:19 | martin.panter | create |
|