__cdecl or __stdcall on Windows?

I just did some real-world testing (compiling DLLs and applications with MSVC++ and MinGW, then mixing them). As it appears, I had better results with the cdecl calling convention.

More specifically: the problem with stdcall is that MSVC++ mangles names in the DLL export table, even when using extern "C". For example foo becomes _foo@4. This only happens when using __declspec(dllexport), not when using a DEF file; however, DEF files are a maintenance hassle in my opinion, and I don't want to use them.

The MSVC++ name mangling poses two problems:

• Using GetProcAddress on the DLL becomes slightly more complicated;
• MinGW by default doesn't prepend an undescore to the decorated names (e.g. MinGW will use foo@4 instead of _foo@4), which complicates linking. Also, it introduces the risk of seeing "non-underscore versions" of DLLs and applications pop up in the wild which are incompatible with the "underscore versions".

I've tried the cdecl convention: interoperability between MSVC++ and MinGW works perfectly, out-of-the-box, and names stay undecorated in the DLL export table. It even works for virtual methods.

For these reasons, cdecl is a clear winner for me.

The biggest difference in the two calling conventions is that "__cdecl" places the burden of balancing the stack after a function call on the caller, which allows for functions with variable amounts of arguments. The "__stdcall" convention is "simpler" in nature, however less flexible in this regard.

Also, I believe managed languages use stdcall convention by default, so anyone using P/Invoke on it would have to explicitly state the calling convention if you go with cdecl.

So, if all of your function signatures are going to be statically defined I would probably lean toward stdcall, if not cdecl.

In terms of security, the __cdecl convention is "safer" because it is the caller that needs to deallocate the stack. What may happen in a __stdcall library is that the developer might have forgotten to deallocate the stack properly, or an attacker might inject some code by corrupting the DLL's stack (e.g. by API hooking) which is then not checked by the caller.I don't have any CVS security examples that show my intuition is correct.