RE: [xml] Win32/MSVC Facelift

Hello Mark, all. 

What about delivering xmlversion.h in a condition ready to 
use?  cgywin and unix will all 
overwrite this from, 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

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

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

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

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


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