[Zlib-devel] zlib gzopen_w function added

[Jan Seiffert]

2012/3/17 William A. Rowe Jr. <wrowe at rowe-clan.net>:
> On 3/16/2012 10:58 PM, Mark Adler wrote:
>>
>> I have added a gzopen_w() function to permit wide character path names in Windows.  For those with Windows, please give it a shot and let me know if it works.  Thanks.
>
> Thanks for your effort, I can't possibly match your stamina!
>
> The right way to solve this puzzle is not wchar_t's,

While i don't like wchar_t like the next one ...

> and I very
> strongly encourage you to retract the miguided effort.  MS tried
> and failed for more than a decade,

... at least for WIN32, MS succeded, kind of. Nearly all API exists as
a *A and a *W function, the *A version mostly only forwarding to the
*W function after an alloc and mbtows and free at the end.
Modern Windows is UTF16 internally, they are only very good at keeping
it backward compatible.
And the *W functions are the only sane way to represent Scripts from
other languages (or languages not in your codepage) on Windows.
Period.
The *A Functions are bound to this CodePage Mumbo Jumbo, with all this
braindamage of ACP, and OEM-Codepage, and what not. And the
UTF-Codepage (65001) is deprecated/not supported for use as sytem code
page (would prop. break to much code which thinks one byte is one
char). So while they keep functioning like they used to, they are the
same PITA as they always where when you hit the edge cases of your
codepage.

http://stackoverflow.com/questions/166503/utf-8-in-windows
I don't find the link to MS i18n/l10n guru Michael Kaplan ATM where he
talks about their decision that UCS2/UTF-16 is their choice and UTF-8
is not really supported.

But maybe i have no clue, i'm not a windows user.

> PHP is at 6.0 (HA!) and all
> wchar efforts have proven futile.
>

PHP is no standard to meassure by, they are to stupid to fix an
integer overflow...

> We would be very happy if zlib API's spoke utf-8.  Otherwise this
> is altogether a misguided effort.
>

On other systems zlib can't do anything about it. If the underlying
system does not speak UTF-8, what should zlib do? Convert to the
system encoding (whatever that is) which may be lossy? Better convert
yourself or know that UTF-8 can be used. UTF-8 can be put in a char *
anyway, so it can be passed into the API as is.

For WIN32 things look differently.
The *A system functions already do the conversion internally, maybe
lossy, behind your back. But they don't take UTF-8. The only way out
are the *W functions.
And to include an UTF-8 to UTF-16 transform in the normal func... no,
would break code which expects the handling as is.

> As I said, thank you!!!  We need more developers of your stamina
> who can withstand fair and unfair criticism :)
>
> Yours,
>
> Billl
>

Greetings
Jan

-- 
˙qɐɥ ʇɟnɐʞǝƃ ʎɐqǝ ıǝq ɹnʇɐʇsɐʇ ǝuıǝ ɹıɯ ɥɔı sɐp lɐɯ ǝʇzʇǝl sɐp ʇsı sɐp
'ʇɯɯɐpɹǝʌ