Re: [xml] windows binary with different calling conventions

[Igor Zlatkovic <igor zlatkovic com>]

> Hi again Igor,

Ho again Gustaf :-)

> Just to tell ya, it became two beers that other night :-)

May it remain so, night for night :-)

> The major problem I had with linking was that I was using stdcall and
> the lib uses cdecl. What's irritating is that there's no problem merging
> any call with another. As long as you specifically type _cdecl in a
> stdcall-program that function will be treated as cdecl. So you can use
> different calls for different functions.

Right. Stdcall and cdecl functions can call each other, there are no
restrictions on that. One just must tell the compiler which is which.

> If you added a macro definition CDECL that is empty declared except for
> in WIN32 where it's declared to  _cdecl, and added CDECL before every
> call to the library, then anyone could use the library, whatever calling
> convention they use in the rest of their application. What about that
> idea?
> I know that you'll have a dozen of reasons why this is bad, why you
> don't like that "type of solution", but I'm just curious to here what
> they are ;-)

There were discussions about this before. There were people who wanted to
specify the calling convention this way, others wanted to specify an
exportable symbol, there were even some who wanted the struct alignment to
be specified in evey header file.

All of this was refused. The majority of developers agreed that this
unnecessarily complicates the header files. If every aspect of this were
followed, we would end up with several macros in every function declaration
and the return type would have to be somewhere between them. A very ugly
picture that would be. Windows is the only platform where any of those
macros is ever needed. Most of the folk who makes libxml works on Unix and
there was no justification to confront them with all this for no other
reason but own laziness.

> I had three link errors when I used stdcall (since I used three calls to
> the lib). Switching the entire app to cdecl it work perfectly. Switching
> back to stdcall but adding _cdecl to one of your declarations in one of
> your .h-files, decreased it to 2 link errors. I guess I could add _cdecl
> to every of your functions and every would work.

Of course it would work. However, the majority here agrees that this should
not be a problem for libxml to solve. Cdecl corresponds to what is used on
other platforms, and that is the reasonable default for windows. It is also
the only possibility, because libxml does have functions which accept
variable number of parameters. It is therefore your burden to declare your
functions as stdcall if you want to use that calling convention.

Basically, stdcall results in an executable few precent smaller than cdecl,
with no improvement in execution speed. It can be argued if this makes sense
or not. Windows API was a try to design a whole OS interface without the
need for variable argument lists. It failed, with the function FormatMessage
as a proof, which requires you to build a va_list array before you call it.

Whatever, we are not without an ear. If you or anyone has a good reason why
specifying the calling convention should be done by libxml and not by you,
then lets hear it.

Ciao,
Igor