GNOME Bugzilla – Bug 309757
Missing XMLCALL in callback types
Last modified: 2009-08-15 18:40:50 UTC
Please describe the problem: The xmlIO callback types are missing the XMLCALL to enforce correct calling convention. Thus changing to a different default calling convention prevents compilation. Steps to reproduce: --- xmlIO.old.h 2005-07-07 23:56:17.131375000 +0200 +++ xmlIO.h 2005-07-07 23:55:31.725125000 +0200 @@ -31,7 +31,7 @@ * * Returns 1 if yes and 0 if another Input module should be used */ -typedef int (*xmlInputMatchCallback) (char const *filename); +typedef int (XMLCALL *xmlInputMatchCallback) (char const *filename); /** * xmlInputOpenCallback: * @filename: the filename or URI @@ -40,7 +40,7 @@ * * Returns an Input context or NULL in case or error */ -typedef void * (*xmlInputOpenCallback) (char const *filename); +typedef void * (XMLCALL *xmlInputOpenCallback) (char const *filename); /** * xmlInputReadCallback: * @context: an Input context @@ -51,7 +51,7 @@ * * Returns the number of bytes read or -1 in case of error */ -typedef int (*xmlInputReadCallback) (void * context, char * buffer, int len); +typedef int (XMLCALL *xmlInputReadCallback) (void * context, char * buffer, int len); /** * xmlInputCloseCallback: * @context: an Input context @@ -60,7 +60,7 @@ * * Returns 0 or -1 in case of error */ -typedef int (*xmlInputCloseCallback) (void * context); +typedef int (XMLCALL *xmlInputCloseCallback) (void * context); #ifdef LIBXML_OUTPUT_ENABLED /* @@ -77,7 +77,7 @@ * * Returns 1 if yes and 0 if another Output module should be used */ -typedef int (*xmlOutputMatchCallback) (char const *filename); +typedef int (XMLCALL *xmlOutputMatchCallback) (char const *filename); /** * xmlOutputOpenCallback: * @filename: the filename or URI @@ -86,7 +86,7 @@ * * Returns an Output context or NULL in case or error */ -typedef void * (*xmlOutputOpenCallback) (char const *filename); +typedef void * (XMLCALL *xmlOutputOpenCallback) (char const *filename); /** * xmlOutputWriteCallback: * @context: an Output context @@ -97,7 +97,7 @@ * * Returns the number of bytes written or -1 in case of error */ -typedef int (*xmlOutputWriteCallback) (void * context, const char * buffer, +typedef int (XMLCALL *xmlOutputWriteCallback) (void * context, const char * buffer, int len); /** * xmlOutputCloseCallback: @@ -107,7 +107,7 @@ * * Returns 0 or -1 in case of error */ -typedef int (*xmlOutputCloseCallback) (void * context); +typedef int (XMLCALL *xmlOutputCloseCallback) (void * context); #endif /* LIBXML_OUTPUT_ENABLED */ #ifdef __cplusplus Actual results: It compiles again and works pretty nice. Expected results: It compiles again and works pretty nice. Does this happen every time? yes Other information: no
In addition to the above it is currently not possible to compile libxml2 as __fastcall using msvc.net. Also there are a few more places that need correction when rebuilding the library. To solve the issue the below patch introduces two new macros: 1) XMLCDECL which is __cdecl for all windows compilers 2) LIBXML_FASTCALL which can be used to link from a cdecl project to a __fastcall linked libxml2. The patch is here: http://marcus-boerger.de/libxml2-bug309757-20050717.diff.txt And in the hope this eases the process of validation i added a msvc.net project to verify the problems: http://marcus-boerger.de/libxml2-bug309757.zip If you want to verify the mixed build and don't want to rebuild iconv.dll then you also need an updated iconv.h: http://marcus-boerger.de/libxml2-bug309757-iconv.h thanks marcus
Well I can't test them. I have no Windows boz, no licence, no devel environment for it. But thanks for posting those. However sending those inforamtions to the mailing-list is more likely to target Windows users and hence to get meaningful feedback. Could you post this on the list and try to get review from others, then I will feel better trying to apply the patches. They don't look wrong to me but I would preffer to see some feedback before applying them, thanks Daniel
I've updated the patch: http://marcus-boerger.de/libxml2-bug309757-20050718.diff.txt As a side note: If you look closely and miss the changes in trio than relax, windows doesn't need trio since the windows _vsnprintf() is quite a good enough approximation to iso vsnprintf(). And the others shouldn't have problems. If you still want trio there is no problem unless you want to do your own non __cdecl libxml2 builds.
Any change over such big architectural decision like using trio on windows should be publicly asked for review on the list. vsnprintf was severely borken on some version of windows at least, so that doesn't seems a good idea to change. Daniel
That's why i didn't touch trio. What i wrote was just underline why i think it is not necessary to touch it at all.
Okay, following the discussion on the list I applied the patch libxml2-bug309757-20050718.diff.txt and commited to CVS, thanks a lot ! Daniel
This should be closed by release of libxml2-2.6.21, thanks, Daniel