RE: [xml] Win32/MSVC Facelift

["Vakoc, Mark" <Mark_Vakoc jdedwards com>]

> Again, the people who change the standard byte alignment and know what
> they just did are not novices and they should know the dread 
> which might
> come to hunt them. They might as well do a
>  
>     #pragma pack(push,8) 
>     #include <libxml/somefile.h> 
>     #include <libxml/anotherfile.h> 
>     #pragma pack(pop)
>
> in their sources without spending a second thought for the 
> matter. Where
> is the problem? There is no need to microsoftificate libxml 
> header files
> more than necessary.

This works, but hard-codes a value for alignment.  If sometime in the future
it is decided to change the alignment in libxml, all the programs that
include libxml need to be changed as well.  Handling this within libxml
seems the best route, but I digress...

> Is it? __stdcall is a calling convention used by the native Win32 API.
> Entire MS C-runtime uses __cdecl. libxml uses the C-runtime, not the
> native API.

Yes, but the difference is the MS c-runtime headers are properly built to
handle any default calling convention used by the programs compiling against
them.

> > The merits of 
> > this really
> > don't matter, its a fact.  
>
> Then you have another problem which I call a cognitive rule-following
> syndrome. The only important thing is that there is a rule and if the
> rule makes any sense is not of importance, eh?

The merits of using __cdecl vs. __stdcall as a platform standard really
doesn't matter.  The sensible approach is to handle either default calltype
and allow the end user the freedom to choose which they want rather than
impose a __cdecl requirement for every program using libxml.

A change to handle this is major (adding a macro to every function in the
source) yet low risk.  It offers the benefit of removing the need to
maintain the .def.src, and variables and functions would be handled
similarily, i.e. possibly :

#ifdef LIBXML_EXPORTS
#define XMLAPI __declspec(dllexport) __cdecl
#define XMLVAR __declspec(dllexport)
#else
#define XMLAPI __declspec(dllimport) __cdecl
#define XMLVAR __declspec(dllimport)
#endif

void XMLAPI somefunction();
extern XMLVAR int someexportedvariable;

Again, it really comes down to do the project owners (daniel et. al) really
want a powerful msvc implementation or not.  Since 98% of the people use it
on unix, the answer may very well be no.  Its worth discussing the options
here before commiting to any one approach.