FIY: libzip and UTF-8 on Win32

Dirk Hohndel dirk at hohndel.org
Wed Feb 18 14:53:20 PST 2015


On Thu, Feb 19, 2015 at 12:46:34AM +0200, Lubomir I. Ivanov wrote:
> so, i've been bringing this annoying topic multiple times now,
> 
> if Subsurface is built with older libzip, when targeting Win32 there
> was this problem where zip_open() from libzip doesn't work with weird
> UTF-16 encoded paths...etc...
> 
> so i've just downloaded the tip from their mercurial:
> http://hg.nih.at/libzip/
> 
> and tried opening a file from a UTF-8 encoded source file, while the
> filename itself is UTF-16 encoded and it now works (tried multiple
> times) as they seem to have changed their API backend. i clearly
> remember this didn't work.

Yay! That's a good thing. I have at least one user who is stuck and his
downloads from divelogs.de don't work because of this (as far as I can
tell).

> no special compilation flags required with mingw, though i've just
> sent a small patch to their ML, while also asking when the above
> functionality was added.
> 
> so when building the Subsurface Win32 package, using the latest libzip
> master will not introduce this old potential issue that we found.

Of course I read this less than an hour after making (and announcing)
4.4.1 binary packages. Arg.

> at some point it was a GSoC task...then i started porting a C++
> version of a minizip wrapper that i had from before, but due to the
> actual very low chance of this breaking on user setups it wasn't a
> priority.

I build everything from source, anyway, so all I need to do is switch to
the latest master for libzip? Any unintended consequences of doing so?

/D


More information about the subsurface mailing list