[Zlib-devel] RE: [png-implement] Binary-incompatible change in the DLL interface of zlib

[John Bowler]

Ok. the argument push direction is the same.  I don't think anyone would
deny that it (the x86 procedure call convention) is horribly broken and that
universal __cdecl would be a viable fix apart from the compatibility issues.
(This is what happens in x85 Linux isn't it?)

However:

Cosmin:
>John:
>>Even a mixed __cdecl for static lib and __stdcall for DLL would
>>work fine - the (C) application writers would just have to remember to
>>define ZLIB_DLL or not according to what they linked with.  The error
>?happens at build (link) time and is an obvious set of missing symbols.
>
>__cdecl and __stdcall work fine only when the function does not have
>arguments. Otherwise, there are crashes, caused by inconsistent stack
>cleanup (callee in CDECL, caller in STDCALL).

I meant that using __cdecl for the static library and __stdcall for the DLL
*does* work and causes minimal problems.  I didn't mean to imply that it is
possible to fabricate a call to a __stdcall function using __cdecl or vice
versa.

ZEXTERN int ZEXPORT deflate(z_stream *strm, int flush);

#define ZEXPORT __cdecl
	compiler produces symbol: _deflate
#define ZEXPORT __stdcall
	compiler produces symbol: deflate at 8

(or something like that).  It is *impossible* for code compiled with one
calling convention to accidentally call code compiled with a different
convention, there will be a missing symbol at link time.

What I'm trying to say here is that it doesn't matter very much what calling
convention is used just so long as it is explicitly set in the zlib.h header
file (probably via zconf.h).  Compared to the failure of the current header
to do this everything else is a minor problem - including my opinion that
__stdcall throughout is a better choice :-)

John Bowler