[Zlib-devel] FAR pointer magic on 16 bits is not working

Cosmin Truta cosmin at cs.toronto.edu
Thu Aug 7 20:43:40 EDT 2003


Hi,

While making the last changes into what I hope to become the release
candidate, I noticed inconsistencies in the management of FAR pointers
in the new inflate code.

This doesn't show up when testing zlib with the default MSDOS makefiles,
because those makefiles are using the LARGE memory model by default.
In the COMPACT and LARGE memory models, the pointers are "far", and the
use or the misuse of the FAR macro doesn't change anything.

But when I switched to the SMALL or the MEDIUM model, the examples
didn't work. I spent a little time and made a few changes until I
eliminated the compiler warnings, by adding some more FARs in
appropriate places, but EXAMPLE.EXE kept crashing (deflation runs fine,
but inflation crashes). I believe the errors that were not discovered
are hidden by some pointer casts (as you know, casting shuts up
warnings, either if they are caused by a real problem or not).


Here is what we can do:

1. Forget about this problem. Eventually, the support for the small
   16-bit memory models will be purged from zlib.

2. Fix this problem now, before releasing zlib.

3. Fix this problem later, in a future release of zlib.


My advocacy for 1 is the following: we still have the support for the
COMPACT and LARGE 16-bit memory models, where every pointer is a FAR
pointer. If one needs zlib in 16-bit apps with SMALL or MEDIUM memory
models, one could use zlib-1.1.4.

Assuming that the 16-bit support is fully working in zlib-1.1.x (if this
is not the case, we could make a post-mortem 1.1.5 release where those
problems are fixed), we could officially stop maintaining this support.
Otherwise, every new functionality that uses pointers has to be adapted
to it.  Debugging MSDOS crashes caused by near/far pointer inconsistency
is difficult and almost futile (nothing but a toy program would use it,
because even 10 years ago it was so difficult to stay into the 64KB
memory limit). Not to mention that we need a volunteer to do it.


Best regards,
Cosmin





More information about the Zlib-devel mailing list