[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