I have the following code, adapted from pasbzip.pas (bzip2 example)
uses ...bzip2..
const
  BufferSize = 4096;
var
  infile, outfile: Tbufstream;
  decoder: Tbzip2_decode_stream;
  a: array[1..BufferSize] of byte;
  readsize: cardinal;
  Status: boolean;
begin
  Status := False;
  result:=false;
...
  try
    infile.init(SourceFile, stopenread, 4096);
    outfile.init(TargetFile, stcreate, 4096);
    decoder.init(@infile);
    if decoder.status  stok then
    begin
...
      repeat
        readsize := BufferSize;
        decoder.Read(a, readsize);
        Dec(readsize, decoder.short);
        outfile.Write(a, readsize);
      until decoder.status  0;
    end;
    infile.done;
    outfile.done;
...

Code (a, readsize). readsize=0 according to debugger. readsize=cardinal; according to help "an unsigned 32-bit integer". However,
http://wiki.lazarus.freepascal.org/Multiplatform_Programming_Guide#32.2F64_bit seems to imply Cardinal can vary between 32 bit and 64 bit.

Is that the culprit or am I doing anyth else wrong?

Thanks,
Reinier

Does your stream contain at least 4096 bytes? According to the documentation here
http://www.freepascal.org/docs-html/rtl/objects/tstream.read.html the Read procedure does not perform any check.
Important note in case you're not aware of it: Tbzip2_decode_stream is NOT a descendant of Classes.TStream, but of Objects.TStream, thus you should look at the documentation of unit Objects (you can reach it from the above mentioned link).

Also "Cardinal" is always 32-Bit wide. The only types that change depending on bitness are "Pointer", "PtrUInt" and "PtrInt".

Regards,
Sven

Thanks, Sven!

Does your stream contain at least 4096 bytes? According to the documentation here http://www.freepascal.org/docs-html/rtl/objects/tstream.read.html the Read procedure does not perform any check.

Yes, that should be the case, compressed size is 909094 bytes. The file uncompresses nicely with the bunzip2 executable.

Important note in case you're not aware of it: Tbzip2_decode_stream is NOT a descendant of Classes.TStream, but of Objects.TStream, thus you should look at the documentation of unit Objects (you can reach it from the above mentioned link).

Ok, thanks.

Also "Cardinal" is always 32-Bit wide. The only types that change depending on bitness are "Pointer", "PtrUInt" and "PtrInt".

Thanks.
Let me verify if I understand correctly. The wiki article http://wiki.lazarus.freepascal.org/Multiplatform_Programming_Guide#32.2F64_bit says:
FPC defines two types for this: PtrInt and PtrUInt. PtrInt is a 32bit signed integer on 32 bit platforms and a 64bit signed integer on 64bit platforms. The same for PtrUInt, but unsigned integer instead.

Use for code that should work with Delphi and FPC:

{$IFNDEF FPC}
type
  PtrInt = integer;
  PtrUInt = cardinal;
{$ENDIF}

So in Delphi, presumably cardinal varies between 32 and 64 bit, while in FPC it is always 32 bit. Or am I interpreting this incorrectly?

I'll try and upgrade the FPC to SVN first - now at Free Pascal Compiler version 2.6.0-1 [2012/01/13] for i386 maybe it helps... (Probably not).

I can also try the same code on Windows x86 to see what happens there... Any additional tips welcome...

Thanks,
Reinier

Ok, then I don't know right now what the problem could be... sorry.

Yes, you are interpreting this incorrectly. ;)

The code above was meant for older versions of Delphi which did not support 64-bit. There PtrInt and PtrUInt is not defined (newer versions since AFAIK Delphi 2007 definee NativeInt and NativeUInt instead which is supported in FPC 2.6.0 and 2.7.1 as well). Thus the code above simply defines PtrInt and PtrUInt in a way that works for non-64-Bit Delphi versions. In principle you might want to simply use NativeInt and NativeUInt to stay Delphi compatible and just define these two for older Delphi versions where that type does not exist yet (similiar to the above code for Ptr(U)Int).

Regards,
Sven

<snip>

Regards, Sven

Thanks again, Sven, for the thoughtful explanation.

Thanks for the help!

Tested on Windows with original pasbzip from fpc example; also crashes (with both small and large .bz2 files).

very strange that it does work on Linux x64...

Raised bug 21242

Reinier Olislagers wrote

Raised bug 21242

Marco v.d. Voort suggested turning off the include for i386 assembly code.

This fixed the problem (in FPC fixes 2.6, bzip2 code identical with trunk).

I've also uploaded a test case to mantis.

Could somebody comment out the assembly include?

Thanks,
Reinier