[Zlib-devel] New gzio called gzlib

[Paul Marquess]

> 
> On Jan 1, 2005, at 9:12 AM, Paul Marquess wrote:
> > Is it your intention to remove the existing gz* functions from zlib
> > and put
> > them into gzlib?
> 
> Yes, though gzlib would still be distributed with zlib.  There would be
> separate zlib.h and gzlib.h interface headers.  I'm not sure yet if
> zlib.h should automatically include gzlib.h, or whether the default
> build should combine the libraries.

Although I think it makes a lot of sense to separate the zlib core from the
gzip layer, I think care needs to be taken not to break existing
applications that use zlib. Perhaps, by default, the interface provided by
the new zlib should contain (at least) everything that the legacy zlib
exported. Folk that want a cut-down zlib without the gzip function can
explicitly build zlib without the parts they need.

> The motivations for separating them are: a) the gz* functions are
> really an application of the zlib functions, not part of them, b) gzlib
> and zlib both may benefit from independent development and releases,
> and c) the separation would facilitate a libraryless compilation of
> zlib, which I have had several requests for.  (zlib 1.2.2.2 already
> took one step in that direction by removing structure assignments that
> result in hidden memcpy() calls.)

Can we expect gzlib to include the gzip enhancements you have mentioned in
the past, like adding an extra length trailer field for uncompressed data >
2^32? 

> The motivation for writing a new gzlib was mainly performance -- gzio
> was not well buffered and could be rather slow, especially when using
> gzgetc().  gzlib has complete buffering and uses the lower-level i/o
> functions to avoid an extraneous layer of stdio buffering.

As it happens I'm (slowly) finishing off a rewrite of the Perl interface to
zlib. One of the changes I've already made is to remove all dependence on
the gzip functions that zlib provides. This was done for three reasons.

1. The gzip functions in zlib didn't provide an interface to allow a
read/write access to the gzip header info (although you have now provided
that missing part of the interface).

2. Efficiency, for the same reasons you stated.

3. Portability. Perhaps the single biggest issue I got in my mailbox
regarding my Perl module was the problems people had with getting my
interface to work on more obscure operating systems. The issue invariably
boiled down to an unfortunate interaction between the file I/O used by
gzdopen and the way Perl handles file I/O. 

Paul