Re: SV: [xml] windows binary with different calling conventions

[Igor Zlatkovic <igor zlatkovic com>]

>   There is something I fundamentally don't understand. Switching calling
> conventions is a *compiler* job. It does not affect the code *semantic*,
> why on earth should it be implemented at the code level ???
>   Clearly this change must be accessible as a compiler switch, why isn't
> that the proper solution. It has to, that's where the essence of the
> change (and associated checkings must be done).
>   I do not understand your request, and apparently you didn't answer 
> to the people who objected that it has to be kept a switch in the
> Windows compiler call in the "makefile". On UNIX you also got tons of
> various possible compiler options but they are not inflicted on the code.
> Sounds like the old "#pragma pack" and other compiler semantic in code
> abominations, they should be avoided as much as possible, and you still
> didn't prove (at least to me) that they can't be avoided.
>   Mixing semantic layers usually flags that something else is wrong in
> the framework...

That's not the point. Noone wants to change the calling convention at a 
whim. What Gustaf wants is a libxml which states it's calling convention 
in every function's declaration, and that just for the compiler to 
recognise them as cdecl, even if the default is set to something else.

This way, Gustaf need only declare his own app's functions as usual and 
set the compiler switch for stdcall. He believes it is easier to have us 
redeclare libxml than take pains to put __stdcall in the declaration of 
his own functions.

At the very end, Gustaf doesn't really need stdcall. I believe he saw 
MSDN samples, perhaps MS C runtime headers and feels that declaring a 
calling convention in a header is the right way. Had his VS.NET IDE used 
a cdecl default, he would never have noticed anything.

I may be wrong, but that's how I see it.

Ciao,
Igor