[Zlib-devel] zlib 1.2.3.2 available for testing

[Mark Adler]

On Sep 6, 2006, at 4:12 AM, Lasse Collin wrote:
> In other words, 99% of apps on those
> systems can't use any functions of zlib that have z_off_t in their
> declaration. That's why I think it is good to make zlib to use large
> file support by default.
...
> Mark Brown's suggestion to implement both 32-bit and 64-bit  
> versions of
> functions that use off_t is definitely the most correct solution. That
> would keep ABI backwards compatible when adding 64-bit functions.

Wait -- doesn't your second suggestion say to keep the 32-bit z_off_t  
as the default for backward compatibility, in contradiction to the  
first suggestion?  For backward compatibility, the current gzseek()  
and gztell() need to be retained with the current compiler options  
for off_t.  Then the second suggestion would be to add gzseek64() and  
gztell64() functions using a 64-bit type for z_off_t.

The current scheme in configure is to #define _LARGEFILE64_SOURCE and  
use off64_t.  In that case, the original off_t is still an available  
type, which I'd need to define a compatible z_off_t to currently  
compiled zlibs.  I would then use z_off_t for gzseek() and gztell(),  
and off64_t for gzseek64() and gztell64().  Then I can't use - 
D_FILE_OFFSET_BITS=64, since that will redefine off_t, and I won't  
have access to the original.  But then what happens if the user  
application uses -D_FILE_OFFSET_BITS=64 -- then zlib.h can't get at  
off_t!  So what's the solution here?

> Backwards compatiblity with old binaries is the reason why 32-bit
> GNU/Linux supports both 32-bit and 64-bit off_t.

They should have just changed off_t and made everyone recompile.   
What a horrible mess.

> PS. What address should I use to post to this list? Most people  
> seem to
> use @zlib.net, but the headers have
>
>     List-Post: <mailto:zlib-devel at madler.net>
>
> which makes my email client to use that address when pressing  
> "reply to
> mailing-list".

It doesn't matter.  Either zlib.net or madler.net will work -- they  
go to the same place.

mark