FIY: libzip and UTF-8 on Win32

[Lubomir I. Ivanov]

On 19 February 2015 at 00:53, Dirk Hohndel <dirk at hohndel.org> wrote:
> 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?
>

nothing bad should happen to my knowledge as they seem to have only
changed their backend.
hopefully it doesn't break anything...

from what i just saw their cmake setup is quite clean, i just
downloaded the tarball and did:

mkdir build
cd build
cmake -G "MinGW Makefiles" -DZLIB_INCLUDE_DIR=some-path-where-zlib-is ..

but here is the patch that i sent to the ML that fixes a compile bug
for me (attached).

lubomir
--
-------------- next part --------------
diff --git a/zip_source_filep.c b/zip_source_filep_new.c
index 81a4158..d8310c8 100644
--- a/zip_source_filep.c
+++ b/zip_source_filep_new.c
@@ -39,9 +39,11 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
-#ifdef _MSC_VER
-/* MSVC needs <fcntl.h> for _O_BINARY */
+#ifdef _WIN32
+/* WIN32 needs <fcntl.h> for _O_BINARY */
 #include <fcntl.h>
+#endif
+#ifdef _MSC_VER
 /* MSVC doesn't have S_ISREG */
 #define S_ISREG(m) (((m) & S_IFMT) == S_IFREG)
 /* MSVC doesn't have mode_t */