JoshyFun wrote:
>
> Found the bug in URangeDecoder.pas
I am planning on using LZMA in the future (no timeframe available yet), but
could you guys make the fixed code available somewhere in a repository or
as a sub-project of Lazarus CCR?
Otherwise others developers downloading the LZMA SDK from
> Strange, apparently shl/shr are not automatically changed to 64 bit when
> compiling for a 64 bit platform. I don't know why that is the case.
>
> You can force a 64 bit shift by typecasting v to int64.
> At least the person who translated it supposedly knows it. Otherwise, you
> have to go bac
On 25 Jan 2010, at 13:29, Matthias Klumpp wrote:
>
>> I think the code there is currently actually only correct on 64 bit
>> platforms and wrong on 32 bit platforms: it seems that it should read an
>> int64 in little endian format and converts it on-the-fly to the native
>> endianess, but that c
> I think the code there is currently actually only correct on 64 bit
> platforms and wrong on 32 bit platforms: it seems that it should read an
> int64 in little endian format and converts it on-the-fly to the native
> endianess, but that currently only happens correctly on 64 bit platforms.
I
>
On 23 Jan 2010, at 15:12, Matthias Klumpp wrote:
> On Sat, 23 Jan 2010 14:19:23 +0100, Jonas Maebe
> wrote:
>>> Does anyone know why the code fails to work?
>>
>> Not really, but at least the following is will be evaluated differently
>> on 32 and 64 bit platforms:
>>
>> [...]
>> v is a byte,
On Sat, 23 Jan 2010 14:19:23 +0100, Jonas Maebe
wrote:
>> Does anyone know why the code fails to work?
>
> Not really, but at least the following is will be evaluated differently
on
> 32 and 64 bit platforms:
>
> [...]
> v is a byte, i is a longint (integer in Delphi mode). Outsize is an
int64.
> Does anyone know why the code fails to work?
Not really, but at least the following is will be evaluated differently on 32
and 64 bit platforms:
>
> ###
> ~~~
> CodeSequence [-1-]:
> -
>
> var inStre