Here's a patch for minigzip. It changes the type of the err variable to smallint to make it compile again.

The compilation of the example.pas file is also broken. But a missing zutil.pas and subsequent missing pzByteArray implementation make it impossible to fix. Anyone know where to find zutil.pas?

Darius

Just looked at the site of Nomssi, and it appears that the paszlib version he's shipping is also FPC compatible. I could have a look to use that zutil.pas unless someone tells me not to ;)
Who did import this lib initially to fpc? It seems that there are some differences between the two versions, just wondering why.

Darius

googling for paszlib finds, you may wan't to compare whats in there and the version of everything of everything there to the ones on the fpc tree.

http://www.nomssi.de/paszlib/paszlib.html

Op Thu, 7 Sep 2006, schreef Darius Blaszijk:

Zutil has been dumped. It provided a wrapper around getmem/freemem with the only purpose of storing the length of the allocated memory. This is not necessary in FPC.

Just use getmem/freemem.

Daniël

Op Thu, 7 Sep 2006, schreef Darius Blaszijk:

a) We did need it for the FCL.
b) It is unmaintained, so the only way to do maintenance is to import it so we can do the necessary maintenance.

I did a cleanup of the code some time ago to switch from C to Pascal types and kick the zutil unit.

Daniël

Apart from the memory functions, there were also some "new" types declared like pzByteArray. How should I handle that one? Is there an alternative available? Or could we perhaps just import back zutil.pas but without the memory functions?

Darius

Hi Darius,

I remeber strugling throug that as well, shortly after the zutils unit was dumped (post FPC 2.0.2 release). The dzlib unit I use in tiOPF had to change. I remember the memory functions, but will have to check what everything I changed to get dzlib to work again. It might be able to shed some light on your problem.

Will get back to you on this...

Regards,
- Graeme -

Op Thu, 7 Sep 2006, schreef Darius Blaszijk:

Sure, Pbyte.

Or could we perhaps just import back zutil.pas but without the memory functions?

No, there is no reason why you want to use types like Pulong etc. in Pascal. Use of standard types that every Pascal programmer understands, like Pcardinal, makes the code much more readable.

Daniël

Op Thu, 7 Sep 2006, schreef Darius Blaszijk:

Here's a patch for minigzip. It changes the type of the err variable to smallint to make it compile again.

I think I'm going to fix this a different way; the bug is caused by a change from fpc to objfpc mode, which caused all integers to become suddenly 32 bits.

However, arrays of integers are used a lot in the code, so this unnecessarily increases the memory requirements on the paszlib package. To undo this all integer usage would need to be converted to smallint. The best solution is imo to switch it back to fpc mode, as the bug that originally resulted in the switch to objfpc mode is no longer there.

Daniël

One reason to do that is to keep code portable between different Pascal compilers.

in Pascal. Use of standard types that every Pascal programmer understands, like Pcardinal, makes the code much more readable.

Indexing pointers as arrays is not exactly a typical Pascal way of doing things either... And whether or not it's more readable mainly depends on knowing the fact that FPC allows you to do that (and even then it's sometimes confusing, although not in this particular case).

Jonas

Op Fri, 8 Sep 2006, schreef Jonas Maebe:

C compilers. At least, that is why there was a zutil, in C there is no way (pre C99) to get a 16 bit integer for example, and for things like compression libraries it is highly important to have data types of fixed size.

Therefore such libraries need to define custom data types with a lot of ifdef statements, which happens in the C version, which was translated to Pascal.

For Pascal compilers, we have a very stable situation, i.e. a word is 16 bits unsigned. There is only some disagreement about the size of a pointer.

Lets take an example:

  s^.l_buf := puchfArray( @s^.pending_buf^[(1+sizeof(ush))*s^.lit_bufsize] );

... is totally unreadable. What is actually meant here is:

  s^.l_buf := Pbyte(s^.pending_buf) + sizeof(word)*s^.lit_bufsize + 1;

Speaking about paszlib portability, there are many endian issues nobody has ever looked at:

    {put_short(s, s.bi_buf);}
    s.pending_buf^[s.pending] := byte(s.bi_buf and $ff);
    inc(s.pending);
    s.pending_buf^[s.pending] := byte(word(s.bi_buf) shr 8);;
    inc(s.pending);

Sure, I agree here. But the reason to kick zutil was not because there were declarations like "type arrayname = array[0..$ffffffff] of byte", in fact, such types are still in the code. I consider such types perfect Pascal code.

Daniël

Op Fri, 8 Sep 2006, schreef Daniël Mantione:

For Pascal compilers, we have a very stable situation, i.e. a word is 16 bits unsigned. There is only some disagreement about the size of a pointer.

... of an integer.

Daniël

I'm only talking Pascal compilers: this is a unit part of a package which is available for different Pascal compiler, so people using different Pascal compilers (apparently) use the unit and the types declared to it.

I'm not talking about the reason for the original C implementation, but the reason to include the unit in FPC (possibly without the special memory allocation functions, although those as well may be used by external code which then may have to be ifdef'ed for FPC).

Not knowing what this is for, this may be right (maybe it's when compressing and the zipped data must always be stored little endian?) or wrong...

The problem is that it breaks code which depends on zutil and the types declared in it.

Jonas

Op Fri, 8 Sep 2006, schreef Jonas Maebe:

There is no need for this unit in order to be able to support different Pascal compilers.

There are no endian conversions at all in the paszlib package, which is IMHO impossible for correct behaviour but many of these constructions. To be sure, can you test minigzip on OS X?

Zutil is internal paszlib use only, it is not part of the published interface.

Daniël

It is needed if the package(s) for other Pascal compilers include(s) this unit and if people depend on it.

It works fine (I compressed a file with minigzip and uncompressed it with gunzip).

But it is nevertheless used by external code according the posts in this thread. It doesn't cost us anything to include it, except for a couple hundreds of bytes.

Jonas

Actually, it doesn't: decompressing with minigzip fails.

Jonas

It's even stranger: minigzip uncompresses the file fine (created with gzip), the result is bytewise identical to the original, yet it complains about a "data error".

Jonas

Op Fri, 8 Sep 2006, schreef Jonas Maebe:

Perhaps there could be an endian issue in the crc code?

Daniël

Op Fri, 8 Sep 2006, schreef Jonas Maebe:

I think you misread something, as we were talking about minigzip and example.pas. If there is any compatibility issue, I have no problem to provide it, let that be clear. However, it would look strange to me since the public interface, paszlib.pas, used longints instead of zutil types, so in fact nobody should have zutil in his uses clause.

Daniël

Op Fri, 8 Sep 2006, schreef Jonas Maebe:

I think I found the problem:

function getLong(s : gz_streamp) : cardinal;
var
  x : packed array [0..3] of byte;
  c : integer;
begin
  { x := cardinal(get_byte(s));  - you can't do this with TP, no unsigned
longint }
  { the following assumes a little endian machine and TP }
  x[0] := Byte(get_byte(s));
  x[1] := Byte(get_byte(s));
  x[2] := Byte(get_byte(s));
  c := get_byte(s);
  x[3] := Byte(c);
  if (c = Z_EOF) then
    s^.z_err := Z_DATA_ERROR;
  GetLong := cardinal(longint(x));
end;

I've committed a fix.

Daniël