2009/3/6 Alok Aggarwal <Alok.Aggarwal at sun.com>:
>
> 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/Hmm, I'd say the root cause is a compiler bug, in the version of the cc compiler that was used to compile the lofiadm utility that was used to compress the solaris.zlib file. The top bits for the 32-bit variable 't' should have been filled with zero bits with the right shift. The cc compiler that I'm using to compile onnv-gate didn't produce the buggy code: % cc -V cc: Sun C 5.9 SunOS_i386 Patch 124868-07 2008/10/07
