[Zlib-devel] zlib 1.2.4 released!

[William A. Rowe Jr.]

On 3/17/2010 8:28 PM, Hiroshi Kuno wrote:
>>>> gzdopen() gets a file descriptor that was opened in the app.
>>>
>>> A 'file descriptor' is not a 'CRT object'.
>>
>> Yes, it is a CRT object. The fd is an index to an array of crt structs of which
>> HFILE is but one member.  Remember 'fd's support several posix modalities which
>> aren't part of the Win32 API, so more context is required.
> 
> I think that gzdopen() should be removed from DLL. gzdopen() can be used only with static-lib.

That's what I point to as the knee-jerk (reflex) reaction.

I'm actually pondering implementing gzdopen() as a crt agnotisic macro wrapper, where
it would ultimate pass that binary's HFILE to the underlying library.

But the existing design works for everyone using the same crt as their zlib library,
whether compiled-in (as you suggest) or sharing a common crt lib.  Developers can
compile zlib far more easily than the typical open source package.

The fact that the MS Windows Visual C++ team is making poor design choices should
NOT become a factor in the design of the zlib API.

The zlib API should not distinguish between static/dynamic applications, but just
help make those choices easier.