Re: [xml] The issue around LoadLibrary on Windows

[Earnie Boyd <earnie users sourceforge net>]

On Thu, May 24, 2012 at 11:01 PM, Daniel Veillard wrote:
> On Wed, May 23, 2012 at 05:41:35PM +0800, Daniel Veillard wrote:
> > Â C.f. the bug Fix windows unicode build
> > Â https://bugzilla.gnome.org/show_bug.cgi?id=638650
> >
> > and the previous discussions here:
> >
> > Â http://mail.gnome.org/archives/xml/2008-February/msg00094.html
> >
> > now that the release is done, can we have a final decision on this.
> > As I understand it, LoadLibraryW takes a wchar_t* parameter, while
> > internally we are using only a char * (or xmlChar *) so it makes
> > no sense to try to call LoadLibraryW, and instead of using the
> > macro LoadLibrary which can only break build, calling LoadLibraryA
> > seems to be the simplest.
> > But I'm not a Windows user, and know close to nothing to the platform
> > so I suggest we reopen that debate, or just agree on fixing this.
>
> ÂOkay after the discussions (thanks everybody !) it seems we have
> two choices:
>
> Â1/ change the xmlmodule.h API to use xmlChar * (and hence assume UTF-8
> Â Âstrings), then convert to 16bit encoding and pass that to the W
> Â Âfunctions on Windows.
> Â2/ keep the xmlmodule.h, assume and document that those entry points
> Â Âaccept only ASCII names and use the A functions on Windows.
>
> In any case using LoadLibrary is just broken :-)
>
> ÂI'm strongly weigting on 2/ myself for the following reasons:
> - library names and entry points are usually ascii to avoid a whole
> Âset of problems
> - on the Linux/Unix side the function dlopen and dlsym will be using
> Âuser's locale and libxml2 cannot and should not make any assumption
> Âabout those settings, so the only safe assumption is that those will
> Âwork with ASCII and we can't guarantee behaviour outside of it.
>
> So I am tempted to take the patches using the A versions of the Windows
> entry point but mainly document xmlModuleOpen and xmlModuleSymbol that
> use of character in the given strings outside of ASCII will have
> undefined behaviour (optionally we could add the check in the entry
> points). That way the API is coherent across platforms, and we
> don't change the API/ABI just clarify limitation of use.
>
> ÂAny strong dissent on doing the above :-) ?

Thanks for the summary.  I don't have any dissent but want to suggest
that you may want to consider what Cygwin is doing for this.  They
deal with LoadLibrary issues on a near daily basis.  Here is where
they implement dlopen, dlsym, etc,
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dlfcn.cc?rev=1.53&content-type=text/x-cvsweb-markup&cvsroot=src
and you'll notice that they use the W versions of functions.  I know
they had a large focus on internationalized strings and how to handle
them properly.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd