On Mon, 2 Mar 2009, Alok Aggarwal wrote:
>
> On Mon, 2 Mar 2009, Juergen Keil wrote:
>
>>> (though admittedly it seems a little
>>> odd for LzmaEncode to take a pointer to the compressed
>>> data and not the start of the header)
>>>
>>> I've gotten rid of LZMA_SIZE_OFFSET.
>>
>> The LZMA properties are a 5 bytes header, followed by an 8 byte
>> compressed buffer length, followed by the lzma compressed data.
>>
>> The 8 byte compressed buffer length between the lzma properties
>> and the lzma compressed data confuses me. It was inserted by this
>> piece of code it lofiadm/main.c:
>>
>> dstp = (Byte *)dst;
>> t = *dstlen;
>> for (i = 0; i < 8; i++, t >>= 8) {
>> dstp[LZMA_SIZE_OFFSET + i] = (Byte)t;
>> }
>>
>> Is this length (*dstlen) needed? I don't think we need this 8-byte
>> length field; the lzma compressed data should immediately
>> follow the 5 byte lzma props data.
>
> I believe that the uncompressed size is used by LZMA during
> decompression.
>
>> Ok, changing this now would make new lzma compressed
>> files incompatible with the lzma compressed files that you
>> can find on opensolaris global ISOs. We would be changing
>> the lzma compressed lofi data format.
>>
>> Btw. the 8-byte length field in the solaris.zlib image on
>> osol-0906-108-global-x86.iso are wrong; I would expect
>> to see the value 0x000000000001ffff, but I do find the value
>> 0x0001ffff0001ffff ?? Since nobody is using this data,
>> it doesn't matter...
>
> That's odd, I'm going to pick apart that iso and let you
> know what I see.
The correct value should in fact be 0x000000000001ffff which
is 131071. The reason it was instead 0x0001ffff0001ffff is
because the above code was encoding the dstlen *twice* since
dstlen is a 32-bit quantity (The LZMA specification states that
the uncompressed size be a 64-bit quantity).
This is a bug, thanks for catching it!
I've modified the code such that 't' is a 64-bit quantity,
please see the updated webrev -
http://cr.opensolaris.org/~aalok/lzma-lofi/
Thanks,
Alok
