Hello Jacob, Jacob Rief wrote:
currently I am adding LZMA support to an existing streaming library using your lzlib implementation.
Great!
this is OK, but LZ_decompress_finished only returns 1 after LZ_decompress_read has returned with -1, setting LZ_decompress_errno to LZ_header_error.
Are you feeding any trailing garbage to LZ_decompress_write? Lzlib can decompress concatenated lzip members (compressed data sets). So, if it finds more data after the end of a member, it will try to decode a new header.
This implementation works fine, but from the point of view of an API client, I would expect for cleanness and symmetry reasons that LZ_decompress_finished returns 1 BEFORE LZ_decompress_read returns an error.
This is the intended behaviour of lzlib in absence of trailing garbage. Best regards, Antonio. _______________________________________________ Lzip-bug mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lzip-bug
