[Zlib-devel] zlib gzopen_w function added

[William A. Rowe Jr.]

On 3/17/2012 11:31 AM, Mark Adler wrote:
> On Mar 17, 2012, at 9:08 AM, Jan Seiffert wrote:
>> And to include an UTF-8 to UTF-16 transform in the normal func... no,
>> would break code which expects the handling as is.
> 
> That is exactly what I was concerned about in the first approach (always do a UTF-8 to UTF-16 conversion in gzopen when on Windows), hence why I tried to duplicate what appears to be the standard approach in Windows.  However I don't know enough to know what actual problems might occur.  What specifically might break in that scenario?

For all conventional apps, with no hinting (explicit desire by the dev)
to support foreign characters, it seems zlib needs to keep doing as it
was doing, which means the local code page.  That's fine.  I probably
confused things in my response by focusing on my own use case, and
thinking more generally about the zip puzzle.

For Windows fans only, wide entry points ARE very wonderful!  It's not
a portability thing, its for the sake of the windows focused developer.
But let's stay with Microsoft standard C library conventions?

E.g. _open() becomes _wopen() for the wide-char flavor (_sopen_s becomes
_wsopen_s etc).  We can continue to omit the leading underscore, MS has
decided to make the clib api practically unusable, but that shouldn't
influence other library designers.  If this is targeted at more than
simply windows, then a different convention might be appropriate.

For porting/unix cross compatibility fans, a utf-8 flavor which does the
internal N->W conversion (and calls the windows fooW or wfoo entry point)
would be most helpful, and that's what I'm offering to help with.

If the .dll exposes all three, and the zlib.h with a specific -D'efine
triggers the gzopen -> gzopenW or gzopenU (just an idea, name can change)
#declare, we'll all be happy.  UNICODE or _UNICODE would be a MS standard
define to trigger gzopen -> gzopenW or gzopen -> wgzopen mapping.  We
could add a ZLIB_UTF8 define to switch names to a utf-8 accepting variant.