RE: [xml] Win32/MSVC Facelift

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

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 :

#define XMLAPI __declspec(dllexport) __cdecl
#define XMLVAR __declspec(dllexport)
#define XMLAPI __declspec(dllimport) __cdecl
#define XMLVAR __declspec(dllimport)

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.

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