[Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn

[SourceForge.net]

Patches item #820946, was opened at 2003-10-09 19:06
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn

Initial Comment:
OK, well the title I wanted was "expat.h doesn't work
cleanly for MSVC with non-cdecl default calling
convetion", but there were (reasonable, I guess) length
limitations.

In any case, if you have a project in MSVC that has its
default calling convention set to something other than
cdecl (such as stdcall or fastcall), the prototypes for
the handler functions don't communicate that the
library is compiled to assume cdecl. Things will still
compile fine, however odd behavior occurs at runtime
(for example, my start element handler was called 5
times with the same name and then the thread crashed).
If your callback funcitons are then explicitly declared
cdecl (as they should be) then you have to use casts to
allow you to assign the address of your cdecl handler
functions to the function pointers that the compiler
defaults to the different convention.

I don't suppose many people bother to change the
default calling convention of their projects, but I
have seen fastcall give a 5% boost. XML parsing is not
a significant part of our apps exection time, so it's
not worth recompiling expat to fastcall. It would be
nice if it worked out of the box for us.

I've supplied a patch, that defines a macro XMLCALLBACK
for callbacks, much like the XMLPARSEAPI macro is
defined for API functions. I've tested it with MSVC 7.1
projects that default to both stdcall and fastcall.
Because the preprocessor tests are set up like the ones
for the XMLPARSEAPI macro, I don't think it should
affect any non-MSVC compilers.

Thanks,

Marsh Ray
marsh *period* ray *atsign* barrsystems *period* com


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-10-13 15:53

Message:
Logged In: YES 
user_id=3066

Ok, I think I understand this one now.  ;-)  Thanks for the
careful response.

While I think that interaction between libraries and
compiler switches will probably always be a source of
frustration, we should be able to make this particular
problem go away.  I'll gladly support a solution which
always forces both call directions to always use cdecl.

Hopefully I'll be able to fix this in the next couple of
days; I know I won't have time tonight, though.  ;-(

----------------------------------------------------------------------

Comment By: Marsh Ray (marshray_bs)
Date: 2003-10-13 15:43

Message:
Logged In: YES 
user_id=883966

> How does it work when you build the library
> with your calling convention?

Expat.dll does not compile with not compile with a default
calling convention other than __cdecl. It produces 65
errors, here's a sample:

--------------------Configuration: expat - Win32
Debug--------------------
Compiling...
xmlparse.c
c:\expat-1.95.6\source\lib\xmlparse.c(629) : error C2373:
'XML_ParserCreate' : redefinition; different type modifiers
        c:\expat-1.95.6\source\lib\expat.h(194) : see
declaration of 'XML_ParserCreate'

These errors correspond 1:1 with the public API functions
defined in expat.h. In expat.h the API functions are
declared explicitly cdecl with the XMLPARSEAPI macro. Their
definitions (in xmlparse.c for example) do not specify a
calling convention, so they follow the default for the project.

> If it works OK then we should not force any
> calling convention on the callbacks but
> simply document that the pre-built binaries
> were compiled with cdecl as default.

Currently, we're using a Perl script to patch 1.95.1 to
allow it to be compiled as fastcall and thus be compatible
with our code. We'd like to use the newer release, and for
obvious reasons, we'd like to get on the official codebase.

The "callforward" API functions define a specific calling
convention, all we need is to have one specified on the
callbacks.

Thanks,

Marsh Ray
marsh *period* ray *atsign* barrsystems *period* com


----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-10-11 16:10

Message:
Logged In: YES 
user_id=290026

How does it work when you build the library
with your calling convention?

If it works OK then we should not force any
calling convention on the callbacks but simply
document that the pre-built binaries were compiled
with cdecl as default.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127