On 2012-03-28 Mike Melanson wrote: > *However!* Studying the source code in that directory demonstrated > what was wrong in my own sample app-- I need to call xz_crc32_init() > before the other functions. I see that's mentioned near the end of > xz.h; perhaps it warrants an earlier mention.
XZ Embedded has been written primarily for the Linux kernel and there you don't need xz_crc32_init() except in decompress_unxz.c. So in the Linux context it's better to keep the xz_crc32_init() docs at the end of xz.h. I'm sorry that you didn't notice this or the existence of xzminidec earlier. I added a reference to xzminidec.c to README. > Anyway, I got past that problem. It should be noted that > "--check=crc32" really is necessary for compressed data if Embedded > XZ will be chewing on it. Yes. This is mentioned in linux/Documentation/xz.txt. The existence of this file is pointed in README. > The library returns XZ_OPTIONS_ERROR otherwise, but only on the first > call. If you call xz_dec_run() again, decoding will proceed fine (and > accurately). I figured this out when I made a mistake in my decode > loop and didn't terminate on error. Calling xz_dec_run() again after XZ_OPTIONS_ERROR leads to undefined behavior in sense that I haven't thought what will happen. liblzma would keep returning the same error code if one calls lzma_code() again after an error, but in XZ Embedded I skipped such things to make the code smaller. -- Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
