为什么Cdecl调用在“标准” P /调用约定中经常不匹配？

小编典典

为什么Cdecl调用在“标准” P /调用约定中经常不匹配？

我正在研究一个相当大的代码库，其中的C ++功能是从C＃调用的。

我们的代码库中有很多调用，例如…

C ++：

extern "C" int __stdcall InvokedFunction(int);

使用相应的C＃：

[DllImport("CPlusPlus.dll", ExactSpelling = true, SetLastError = true, CallingConvention = CallingConvention.Cdecl)]
    private static extern int InvokedFunction(IntPtr intArg);

我已经搜寻了网（尽我所能）以了解为什么存在这种明显的不匹配。例如，为什么在C＃中有一个Cdecl，而在C
++中却有__stdcall？显然，这导致堆栈被清除两次，但是，在两种情况下，变量都以相同的相反顺序被压入堆栈，这样我就看不到任何错误，即使在发生以下情况时也可能清除返回信息在调试过程中尝试跟踪？

从MSDN：http : //msdn.microsoft.com/zh-
cn/library/2x8kf7zx%28v=vs.100%29.aspx

// explicit DLLImport needed here to use P/Invoke marshalling
[DllImport("msvcrt.dll", EntryPoint = "printf", CallingConvention = CallingConvention::Cdecl,  CharSet = CharSet::Ansi)]

// Implicit DLLImport specifying calling convention
extern "C" int __stdcall MessageBeep(int);

再一次，extern "C"在C
代码和CallingConvention.CdeclC＃中都有。为什么不CallingConvention.Stdcall呢？或者，为什么__stdcall在C
中呢？

提前致谢！

阅读 292

2020-05-19

共1个答案

小编典典

这样的问题在SO问题中反复出现，我将尝试将其变成（长）参考答案。32位代码因长期不兼容的调用约定而备受困扰。关于如何进行函数调用的选择很久以前就很有意义，但如今在后端却是一个巨大的难题。64位代码只有一个调用约定，无论谁要添加另一个调用约定，都将被发送到南大西洋的小岛。

除了Wikipedia文章中的内容，我将尝试注释它们的历史和相关性。出发点是，如何进行函数调用的选择是传递参数的顺序，参数的存储位置以及调用后如何清理。

__stdcall通过在16位Windows和OS / 2中使用的较旧的16位pascal调用约定，将其引入Windows编程。它是所有Windows api函数以及COM使用的约定。由于大多数pinvoke都是用于进行OS调用的，因此，如果未在[DllImport]属性中明确指定，则Stdcall是默认设置。其存在的唯一原因是它指定被叫方清理。它产生了更紧凑的代码，这在他们不得不将GUI操作系统压缩在640 KB RAM中的时代非常重要。它最大的缺点是很危险。调用者假定的函数参数与被调用者实现的对象之间的不匹配会导致堆栈变得不平衡。反过来，这会导致极其难以诊断的崩溃。
__cdecl是用C语言编写的代码的标准调用约定。其存在的主要原因是它支持使用可变数量的参数进行函数调用。在C代码中常见，具有诸如printf（）和scanf（）之类的功能。副作用是，由于调用方知道实际传递了多少个参数，因此清除的是调用方。在[DllImport]声明中忘记CallingConvention = CallingConvention.Cdecl是一个非常常见的错误。
__fastcall是一个定义较差的调用约定，具有相互不兼容的选择。这在Borland编译器中很普遍，该公司曾经在编译器技术方面很有影响力，直到它们瓦解。也是许多Microsoft员工的前雇主，包括C＃声望很高的Anders Hejlsberg。它的发明是通过将某些参数传递给CPU寄存器而不是堆栈来使传递参数的成本降低。由于标准化不佳，托管代码不支持该功能。
__thiscall是为C 代码发明的调用约定。与__cdecl非常相似，但它还指定了如何将隐藏的类对象的此指针传递给类的实例方法。C中的额外的细节超越C.虽然它看起来很容易实现，在.NET的PInvoke编组并没有支持它。您不能使用C 代码的主要原因。复杂性不是调用约定，而是 this 的正确值 __指针。由于C 对多重继承的支持，这可能会令人费解。只有C 编译器才能弄清楚到底需要传递什么。而且只有生成C 类代码的完全相同的C ++编译器，不同的编译器才对如何实现MI和如何对其进行优化做出了不同的选择。
__clrcall是托管代码的调用约定。它是其他指针的混合体，该指针像__thiscall一样传递，优化参数像__fastcall一样传递，参数顺序像__cdecl一样传递，而调用者清理像__stdcall一样传递。托管代码的最大优势是内置于抖动中的 验证程序 。这可以确保在呼叫者和被呼叫者之间永远不会存在不兼容性。因此，设计人员可以利用所有这些约定的优点，而不会带来麻烦。尽管有使代码安全的开销，但托管代码如何与本地代码保持竞争力的示例。

您提到extern "C"，了解这一点的意义对于互操作性生存也很重要。语言编译器通常用额外的字符来修饰
导出函数的名称。也称为“名称修改”。这是一个很烂的把戏，永远不会停止造成麻烦。并且您需要了解它以确定[DllImport]属性的CharSet，EntryPoint和ExactSpelling属性的正确值。有许多约定：

Windows API装饰。Windows最初是一个非Unicode操作系统，对字符串使用8位编码。Windows NT是第一个成为Unicode核心的代码。这导致了一个相当大的兼容性问题，旧代码将无法在新的操作系统上运行，因为它将8位编码的字符串传递给需要utf-16编码的Unicode字符串的winapi函数。他们通过写两个解决了这个问题 __每个winapi函数的版本。一个使用8位字符串，另一个使用Unicode字符串。并通过在旧版本名称的末尾粘贴字母A（A = Ansi）和在新版本末尾粘贴W（W =宽）来区分两者。如果函数不使用字符串，则不添加任何内容。Pinvoke编组器会自动处理此问题，而无需您的帮助，它只会尝试查找所有3个可能的版本。但是，您应该始终指定CharSet.Auto（或Unicode），而遗留函数将字符串从Ansi转换为Unicode的开销是不必要的，而且是有损失的。
__stdcall函数的标准修饰符是_foo @ 4。前导下划线和@n后缀，表示参数的组合大小。如果调用者和被调用者不同意参数数量，则此后缀旨在帮助解决令人讨厌的堆栈不平衡问题。效果很好，尽管错误消息不是很好，但是pinvoke marshaller会告诉您它找不到入口点。值得注意的是，Windows在使用__stdcall时未使用此修饰。这是有意的，使程序员可以正确设置GetProcAddress（）参数。pinvoke编组器也会自动处理此问题，首先尝试使用@n后缀查找入口点，然后尝试不使用后缀。
cdecl函数的标准修饰符是_foo。单个下划线。Pinvoke编组器会自动对此进行分类。可悲的是， stdcall的可选@n后缀不允许它告诉您您的CallingConvention属性是错误的，损失很大。
C 编译器使用名称修饰，产生真正奇怪的名称，例如“ ?? 2 @ YAPAXI @ Z”，即“ operator new”的导出名称。由于它支持函数重载，因此这是必不可少的。并且它最初被设计为使用旧的C语言工具来构建程序的预处理器。因此，有必要通过给它们赋予不同的名称来区分a void foo(char)和void foo(int)重载。这是extern "C"语法起作用的地方，它告诉C 编译器不要将名称修饰应用于函数名称。大多数编写互操作代码的程序员都故意使用它来使另一种语言的声明更易于编写。实际上这是一个错误，装修对于发现不匹配非常有用。您将使用链接器的.map文件或Dumpbin.exe / exports实用程序来查看修饰的名称。undname.exe SDK实用程序非常方便，可以将错误的名称转换回其原始C ++声明。

因此，这应该清除属性。您使用EntryPoint给出导出函数的确切名称，这可能与您想要在自己的代码中调用的函数不完全匹配，尤其是对于C
++杂乱的名称。而且您使用ExactSpelling告诉pinvoke编组不要尝试查找替代名称，因为您已经给了正确的名称。

我现在要护理我的抽筋。您的问题标题的答案应该很清楚，Stdcall是默认选项，但与用C或C ++编写的代码不匹配。而且您的[DllImport]声明不
兼容。这应该在PInvokeStackImbalance托管调试器助手的调试器中产生警告，该调试器扩展旨在检测错误的声明。而且可能会导致您的代码随机崩溃，尤其是在Release版本中。确保您没有关闭MDA。

2020-05-19