error using MacPorts zlib, not present with system zlib?

[Adam Mercer]

On Wed, Feb 22, 2012 at 15:50, Eric Cronin <ecronin at macports.org> wrote:

> I'm not near a Mac right now, but I believe the system version of zlib is
> pretty ancient.  In version 1.2.4 there was a "Wholesale replacement of gz*
> functions with faster versions" according to zlib.net, one of which I
> suspect was the replacement of the gzgetc() function with a macro.

Looks like it, Lion seems to have zlib 1.2.5 which has a standard
fucntion prototype for the gzgetc() function whereas 1.2.6 in MacPorts
gzgetc() is indeed a macro.

> C treats void* very unsafely, silently converting it to and from other
> pointer types whenever it knows how.  So converting the gzFile* gzopen()
> returned to the void* 'file' is legal.  Then, if gzgetc() is an actual
> function declared as 'char gzgetc(gzFile*)' the compiler will allow the
> void* be passed to the function, and within the function it is treated as a
> gzFile*.  But if gzgetc is just a macro the compiler doesn't know to convert
> 'file' to a gzFile*, so you get errors about trying to treat void as
> struct/union.  If the API said gzgetc took a void* they would fix this by
> casting "g" to a gzFile* inside the macro that replaced the function, but
> the API doesn't say this, and so the zlib authors don't... The current
> version is actually both faster and safer since it catches this type of
> void* abuse.
>
> So tldr answer: patch the port using libz to use a gzFile* or to cast the
> void* gack to a gzFile* before calling functions expecting a gzFile*.

I ended up applying a patch to the port that casts the void* pointer
to gzFile and that allows it to build, but the upstream developer
didn't like that approach. But this analysis is interesting and
imagine this build error will be seen on other platforms that have
zlib-1.2.6.

Thanks for the help.

Cheers

Adam