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 _______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
