[fpc-pascal] LZMA Algorithm fails on 64bit

JoshyFun joshyfun at gmail.com
Tue Jan 26 17:30:00 CET 2010


Hello FPC-Pascal,

Tuesday, January 26, 2010, 4:14:07 PM, you wrote:

>> Yes and the hunting was not easy :( fortunatly the code is quite
>> small.
MK> Cool! Many thanks for that fix! I was reviewing the code for nearly two
MK> days without any usable result.

Well I use a quite simple approach a lot of "writeln" after each
variable assignement in the main loop using:

writeln({$I %LINE%},variable);

Run the same program in both 32 and 64 bits and apply a diff between
both outputs, this reveals the wrong assigned variable in main loop.
Then take the function that produces that value and do the same
inside. I spend most time rebooting the machine from 32 to 64 bits :)
I think I must install a virtual 32 bits machine in my 64 bit OS :)

MK> I did a lot of testing, and the fixed version performs quite well. I now
MK> pushed it to the repository of my project which uses the SDK. If there are
MK> problems, I'll notify you, if everything works for a longer time, I can say
MK> the code has been well-tested for Lazarus-CCR.

Fine!. But simply decompressing a large chunch of data should reveal
any possible hidden bug as decompression is almost all the same the
same operation over and over again.

PS: Can anybody comment if this is expected ?

32 bits: ($80000001 - 1) shr 31 = 1
64 bits: ($80000001 - 1) shr 31 = -1
64 bits: DWORD($80000001 - 1) shr 31 = 1

-- 
Best regards,
 JoshyFun




More information about the fpc-pascal mailing list