Re: [xml] The issue around LoadLibrary on Windows

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

and the previous discussions here:

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,
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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]