RE: SV: [xml] windows binary with different calling

["Zlatkovic, Igor" <Igor Zlatkovic Dresdner-Bank com>]

>   Okay, thanks a lot for going through the work of explaining this.
> The remaining questions I have are not technical anymore:
>   - how many people are left out if this is not provided by default
>   - how bad it is to actually let people start distributing libxml2
>     DLLs using the non-standard calling conventions.

  Producing and distributing several binaries which differ in no more than
calling convention is not very good, beter change the headers. Imagine all
those bug reports where something crashes and imagine us trying to reproduce
them using the right binary.

>  The second point is an interop problem, if I understand correctly
> the goal of that change is precisely to generate shared libs (because
> libxml2 is not compiled in) and have those libs use different calling
> conventions. To what extend allowing this will create new 
> compatibility
> problems ?

Allowing what, you mean modifying the headers? On Windows it won't create
any new problems. To the users on Unix it won't bring grief either. But what
will happen to those scripties which parse the headers for some reason, when
they suddenly have two macros in a function prototype, that I don't know.

>  I think the C parser script I have in python is good enough that it
> might be able to generate those change automatically with some work
> (like the protoize tool coming from the gcc source distribution).
> I'm not tempted to change the distribution, but maybe provide a tool
> to help the 1% (maybe more, maybe less) of the users which may need
> this functionality. The idea of manually editing and maintaining this
> is not something I'm ready to commit for at this point, and Igor seems
> quite reluctant too...

  Hm, maintaining such tool would perhaps be more troublesome than having
those macros directly in the headers. You know that the folk would learn
about the tool's existence only after they would post another plea for cdecl
declarations to this list. Still some would complain about the
inconvenience, stating that macros in the headers would be more intuitive. 
  I'd rather do it Aleksey's way and add a configuration option to
win32/configure.js which gives a stdcall switch to the compiler, hoping that
the compiler will handle the functions with variable parameter lists
gracefully.

  The following is the only case where working on this would make sense: 
  Imagine you write an app and need libxml and some other unrelated library,
call it libfoo. Both you download as binaries. Libxml uses cdecl calling
convention, libfoo uses stdcall. Neither library specifies its calling
convention in its public headers.
  Now, if you must include both libraries in your app, you are out of luck.
You can set the default calling convetion the compiler should assume if none
is declared, but which ever you set, one of the libraries will have it
wrong. The result is that either libxml or libfoo cannot link to your app.
In this situation, you must modify the headers of either libxml or libfoo,
or you must recompile one of them using the other's calling convention. 
  Note that you have no problem with your own calling convention, your app
would work good with any. You have a problem with the difference in calling
conventions between libxml and libfoo, and the fact that none of the two
specifies what it uses. If one would specify it, it would be enough.
  This is the only case where developer has problems brought to her by
others. This case is a legitimate reason to do the declarations. Is there
anyone with exactly this problem? If not, then it remains a theory.

  But most cases are different. Mostly stdcall appears because someone at
Microsoft thought to put it as default in VC IDE. Developers make projects
by simply following the click-next-click-finish wizardry, without spending a
second thought. Those who do it with a purpose and who have any real benefit
from a change in the calling convention are rare, if there is anyone at all.
  Precisely that is what gives me reluctance. All the effort would not
happen because someone needs it badly, it would be just for someone's whim.
In their ignorance, people create this sort of trouble themselves and then
they come telling I should make libxml more Windows-conform.

Ciao,
Igor