Re: libidn 1.29 static lib / msvc12 c++ / windows & 64bit issues

[Simon Josefsson]

Tom Clunie <address@hidden> writes:

> Hi, I encountered two issues using the above.

Hello Tom.  Thanks for the report.

> 1- Unable to link to a static library of libidn unless I define IDNAPI
> prior to idna.h.  The lib was built using the provided MSVC solution file
> in the /windows directory.  If IDNAPI is not defined as below, I get linker
> errors even after I reference the static lib.  I'm guessing this is a
> decoration issue.
> Example:
> MyFile.cpp
> #define IDNAPI   // if I remove this line, i get linker errors
> #include <idna.h>

Does it help to add

#define LIBIDN_STATIC

instead?

It should amount to the same thing (an empty IDNAPI).

You are right that this is a decoration issue, IDNAPI is prefixed to all
function definitions.  The code right now assumes that you are building
a DLL on Windows, unless LIBIDN_STATIC is defined.  Is there a
reasonable CPP symbol that is available (for use in a header file,
consumed by the library user) and set iff you are linking to a static
library?  Maybe it is simpler to just say that if you are linking libidn
statically, you have to #define IDNAPI or LIBIDN_STATIC.

> 2 - 64bit size_t / glong assignment error causing failure
>
> Calling idna_to_ascii_8z with any UTF-8 input leads to an error.  I tracked
> it down to the use of size_t ucs4len in stringprep.c (374) as it gets
> passed down to nfkc.c and assigned at line 457.  The assigned value (64 bit
> uint) is casted to glong (32bit signed int) and assigned a value, which is
> then discarded, leaving the 64bit uint in an undefined state.  This causes
> a malloc failure later on back up the call stack.  This only happens on 64
> bit builds, 32 bit builds work fine, most likely due to size_t being a
> 32bit int vs a 64 bit int, hiding the casting errors.

Is 'long' 32-bit and 'size_t' 64-bit here?  What platform is this?  To
fix this, I would prefer to be able to reproduce the problem.

> For a quick fix to get past the 32/64 bit issue, I redefined 'glong' from
> 'long' to 'long long' in nfkc.c line 43.  Longer term, it might make more
> sense to redefine the 'items_written' parameter to an unsigned int *
> (size_t?) rather than a long *, as I dont think items_written would ever be
> negative (?).  Plus eliminate these casting/platform issues.

I'm considering using libunistring instead of this old glib code.

> Lastly, a windows project for libidn2 would be nice :)  Thanks!

Help is appreciated here, as I don't have a MSVC environment.  I could
copy'n'paste from the current libidn files, and create similar files for
libidn2, but I wouldn't want to ship anything without testing.

/Simon

signature.asc
Description: PGP signature