Hallo, * Jonathan Nieder [Mon, Dec 09 2013, 04:14:20PM]: > tags 729941 + upstream - moreinfo > # documentation > severity 729941 minor > quit > > Eduard Bloch wrote: > > > As far as I remember, zlib always > > returned ..._END when the result stream was completely written into the > > output buffer. And I have seen liblzma behaving the same way but it's > > not the case for the mentioned file(s) according to gdb. Here, the > > returned data (n time return buffer size plus one incomplete buffer) > > summs up to the total size of the stream but in the last cycle lzma_code > > returns LZMA_OK and not LZMA_STREAM_END. Maybe it will become > > LZMA_STREAM_END the next time when lzma_code is called but why should we > > do the extra round? > > Ah, so the confusing behavior is that an LZMA_OK result neither > guarantees that there's more output coming nor that there's no more > output coming? Ok.
Actually, I didn't make my homework and relied on the experiences with zlib. And there is a clear rule: | deflate() returns Z_OK if some progress has been made (more input | processed or more output produced), Z_STREAM_END if all input has been | consumed and all output has been produced (only when flush is set to | Z_FINISH), Z_STREAM_ERROR if... The problem with lzma was: I have set LZMA_CONCATENATED a while ago without reading about all it's consequences and I didn't bother about LZMA_FINISH. And for some weird reason, even in this operation mode LZMA_STREAM_END was returned for almost all files I tested with so the problem hasn't showed up untill a few weeks ago something changed in the non-free archive. If you wish to improve the documentation, please mention LZMA_CONCATENATED and LZMA_FINISH in the description of LZMA_STREAM_END. Regards, Eduard. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
