[fpc-devel] patch minigzip

[Daniël Mantione]

Op Fri, 8 Sep 2006, schreef Jonas Maebe:

> 
> On 8 sep 2006, at 10:37, Daniël Mantione wrote:
> 
> > > > No, there is no reason why you want to use types like Pulong etc.
> > > 
> > > One reason to do that is to keep code portable between different
> > > Pascal
> > > compilers.
> > 
> > C compilers.
> 
> 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.

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

> 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).
> 
> > 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);
> 
> 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...

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?

> > 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.
> 
> The problem is that it breaks code which depends on zutil and the types
> declared in it.

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

Daniël