➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author malin
Recipients malin, miurahr
Date 2020-07-07.06:34:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1594103674.0.0.952060713248.issue41210@roundup.psfhosted.org>
In-reply-to
Content 
There was a similar issue (issue21872).

When decompressing a lzma.FORMAT_ALONE format data, and it doesn't have the end marker (but has the correct "Uncompressed Size" in the .lzma header), sometimes the last one to dozens bytes can't be output.

issue21872 fixed the problem in `_lzmamodule.c`. But if liblzma strictly follows zlib's API (IMO it should), there should be no this problem.


I debugged your code with attached file `lzmabcj.bin`, when it output 12796 bytes, the output buffer still has 353 bytes space. So it seems to be a problem of liblzma.

IMHO, we first wait the reply from liblzma maintainer, if Lasse Collin thinks this is a bug, let us wait for the upstream fix. And I will report the issue21872 to see if he can fix the problem in upstream as well.
History
Date User Action Args
2020-07-07 06:34:34malinsetrecipients: + malin, miurahr
2020-07-07 06:34:34malinsetmessageid: <1594103674.0.0.952060713248.issue41210@roundup.psfhosted.org>
2020-07-07 06:34:33malinlinkissue41210 messages
2020-07-07 06:34:33malincreate