[Zlib-devel] Re: ABI compatibility of zlib 1.0.x, 1.1.x, and 1.2.x

[Cosmin Truta]

On Fri, 5 Dec 2003, Mark Adler wrote:

> On Friday, December 5, 2003, at 02:03  PM, Glenn Randers-Pehrson wrote:
> > I cannot find any statement on the zlib site (FAQ, announcement) about
> > whether zlib 1.2.1 is binary compatible with 1.1.4.  My guess is that
> > it's not guaranteed and that applications using the zlib-1.1.4 shared
> > library should be relinked.
>
> Good question.  The DLL is definitely not compatible.  As for shared
> libraries, that might depend on what compiler options were used in the
> before and after cases.  Assuming that the only variable is zlib, then
> there is one place where there is a possibility of an incompatibility.
> That is the definition of the z_off_t type used by gzseek() and
> gztell().  Portability improvements in zlib 1.2.1 should make that
> defined as off_t more often than zlib 1.1.4.  This only matters if
> off_t is larger than unsigned long.
>
> Any other comments on this?

I know that Cygwin started to use 64-bit offsets since the recent
version 1.5, but I don't know if the proper type "off_t" has 64 bits or
not. This 1.5 branch started only recently, so I don't think there is
much compatibility to break.

In any case, since off_t is not theoretically guaranteed to be identical
to long int, there should be a compatibility note about this, on systems
where sizeof(off_t) != sizeof(long int).

There is also the "incompatibility" introduced by zalloc. Now it uses
calloc() on 16-bit platforms and malloc() everywhere else, and the issue
is that malloc() doesn't zero the memory. If someone used to call zalloc
for private purposes, and expected the memory to be zero'ed, then
surprise. But this is a user's mistake: the specification of zalloc
never made claims about zero-ing the allocated memory. Implementation is
neither documentation nor specification, and the particular behavior of
zalloc in 1.1.4 is not to be set in stone, if it wasn't described in the
specification.

Yet, I think it's good prevention to write about this in some
compatibility notes. Also, I think it's worth writing about _ZLIB_H
versus ZLIB_H. We already had two people asking about it. First,
"zlib.h" can be safely included twice; second, if one really wants to
know if "zlib.h" has been included (although I wonder why...), one
should check ZLIB_VERSION instead of ZLIB_H.


Although it's superfluous, something has to be stated about NOT relying
at all on private symbols that leak out of "zlib.h", or on pieces of
code that do more than the documentation claims.


Best regards,
Cosmin