On Sun, Jun 26, 2011 at 6:20 AM, Lasse Collin <lasse.col...@tukaani.org>wrote:
> On 2011-06-24 Dan Stromberg wrote: > > I'm looking for some example code (C preferred, something else if > > need be) that will: > > > > 1) Demonstrate using liblzma (or whatever library xz-utils produces), > > but producing output in the xz format, not the lzma format. > > > > 2) Demonstrate using liblzma (or whatever) for memory-to-memory > > compression, and memory-to-memory decompression (I'm only > > compressing smallish chunks, and wish to do my own I/O so I can > > sidestep the buffer cache) > > There are two example programs in doc/examples directory in XZ Utils > source. They use multi-call mode to compress big files in a pipe. Data > is passed to and from liblzma via buffers. > Yes, I saw those, though I was suspecting they weren't quite what I was looking for. I did look up what header files to use there though. > If you want a single-call interface (one function to encode or decode a > buffer holding a complete .xz file), see lzma_easy_buffer_encode, > lzma_stream_buffer_encode, and lzma_stream_buffer_decode in > src/liblzma/api/lzma/container.h (or /usr/include/lzma/container.h). > So lzma_easy_buffer_encode sounds like what I want, and I've prototyped something that uses it in C (oddly, it seems easier to prototype in C and create a final product in Python, this time around). Is it safe to assume that lzma_stream_buffer_decode is the way to go for decompression, irrespective of whether one has used lzma_easy_buffer_encode or lzma_stream_buffer_encode to create the compressed input? IOW, that there's no matching lzma_easy_buffer_decode by some other name? > Note that the above functions work on .xz files, not .lzma files, even > though the names might suggest otherwise. The names are what they are > for historical reasons: originally .xz was supposed to be .lzma, > replacing the old .lzma format. > I see. Thank you. > It would be nice to have more tutorial programs for different use cases, > but so far I haven't written anything like that. > Maybe we can kill two birds with one stone here - since I'm prototyping in C, would you find it more useful if it were done as an example program, or as a unit test? > > BTW, does the underlying library API (need to) change much? > > liblzma API is stable. Things will be added, but old things won't change > in incompatible ways. > Just what I was hoping to hear. Thanks!
