RE: [xml] Win32/MSVC Facelift

["Igor Zlatkovic" <izlatkovic daenet de>]

Hello Mark, all. 

> What about delivering xmlversion.h in a condition ready to 
> use?  cgywin and unix will all 
> overwrite this from xmlversion.h.in, but msvc would use the 
> delivered copy.

I don't know. This file is delivered in usable state now, but it wasn't
so few weeks ago, specifically in CVS snapshots. Let's watch the grass
grow for a while and if it grows well, we can always revert to
xmlversion.h.

> Keep in mind that you plan to distribute binaries and 
> libraries that people will use.  
> Not everyone uses 8 byte struct alignmnet.  So their 1byte 
> aligned program
> linked against libxml2 compiled with 8 byte alignment will 
> trigger 0xC000005
> faster than you can say 'quick fix'.  Prepare for those help-me tears.
> Libxml will work fine with any byte alignment, but without 
> #pragma's telling
> the compiler how libxml was built, any program linking against it will
> encounter problems when passing structures in and out of 
> libxml when the
> program was built with something other than 8byte alignment 
> or whatever
> libxml is defined to use.

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.

> Again consider you are distributing binaries and libraries.  
> Use __cdecl, no
> problem -- thats your perogative.  Just remember that the 
> defacto standard
> for msvc programming is the __stdcall method.  

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.

> 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?

> If people want to use the libxml, they are going to include 
> the headers.  If
> there is nothing in the header indicating the calltype, it 
> will use the
> default.  Remember, I may now compiling my program and I have 
> elected to use
> __stdcall.

You may as well elect to download the source and modify the thing the
way it suits your purposes. Having the calling convetion specifier
before each and every function declaration is simply unacceptable. We
have had a similar topic some time ago and I foud that UNIX people,
which make up about 98% of those who use and develop libxml, do not like
the idea. That's how libxml2.def.src came to existence. To be honest, I
don't like the idea either.

> This all boils down to whether you want to create a robust 
> library for win32
> or one that will simply compile.  A robust library allows 
> developers to
> easily incorporate libxml into their projects without 
> requiring them to make
> changes to their existing project (such as byte alignment and calling
> convention).  Sure you can make your project that includes 
> libxml mimic
> libxml in order to function (8 byte, __cdecl).  But all it 
> takes is two
> library creators with differing views on these settings to 
> cause a real
> headache.  

Again, that's what the source code is for, and indeed, it does guarantee
each user the freedom to adapt it to any oddity her environment might
have.

> Take a lesson from nearly every header Microsoft delivers:  a #pragma
> pack(push, x) and #pragma pack(pop) pair, and a macro 
> defining the calling
> convention for each function (i.e. WINAPI, STDMETHODCALLTYPE, 
> etc.).  They
> work, and provide the greatest flexibility.

The definition of 'flexibility' which comes from these lessons is
different to what I have learned so far. 

I think you should modify the sources in a way you think it apropriate.
When you are done, send the patches to this list and let us all see what
have you done. We can type flames here until we wipe our key labels
away, but the majority of the others have no way to know what the heck
are we talking about because they simply use libxml on platforms
different to our. Modifications to the sources you propose are vast and
someone must do it, post it and explain it to the others. Then everyone
can see it, feel it and test if it broke something on his favourite
platform.

Ciao
Igor