Hello Laszlo, well, LZ_decompress_open() invokes at least three allocations on the heap, one of which allocates 64kB.
2009/12/18 Ersek, Laszlo <[email protected]>: > On Fri, 18 Dec 2009, Jacob Rief wrote: > >> Assume the buffers and flags of an LZ_Decoder are filled with some kind of >> data, but for some reason (for instance a stream corruption) you want >> forward up to the next member and start decompression from there. > > Such functionality might be very useful for parallelizing decompression, at > least that of multi-member files. > > >> Thus instead of destroying and recreating a LZ_Decoder, a useful function >> would be to somehow clear the buffers and reset the internal flags to a >> state equivalent to a decoder just after creation, > > Why is the destroy/recreate way unsuitable? Does it incur a performance > penalty too big? (I have no idea.) > > Thanks, > lacos > > > _______________________________________________ > Lzip-bug mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lzip-bug > _______________________________________________ Lzip-bug mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lzip-bug
