通过“太多”安全吗？外部函数的参数？

Question

这种情况只有在没有名称修改的情况下才会发生（我相信），所以下面的代码是C。 假设 Ac 中定义了一个函数 A

void A(int x, int y){
    //Do stuff
}

现在还有一个单独的文件 Bc：

extern "C"{
    void A(int x, int y, int z);
}

void B(){
    A(1, 2, 3);
}

A 最初被声明为只有 2 个参数，但在 Bc 中声明时它有一个额外的参数，并且在 B() 中用第三个参数调用它。 我知道有可能发生这种情况，例如在与 Fortran 子例程链接时，或者在动态链接时。

我想向函数传递额外的参数是不安全的，任何人都可以解释当调用函数并将参数传递给它时内存中发生了什么吗？因此，传递这个既不被使用也不被需要的“额外”参数是多么安全。

额外的参数是否有可能覆盖函数内使用的内存空间？或者，对 A 的函数调用是否在内存中为参数分配空间，然后告诉 A 参数内存块的开头在哪里，A 读出前两个参数并忽略最后一个，使其完全安全？

任何有关该功能的信息都会很有启发，谢谢。

Answer 1

链接是实现定义的，所以没有办法明确地说。

也就是说，C 的其他功能（特别是 vardic 参数）强制实现通常允许它的实现。

例如，我不知道如果您编写以下内容，任何实现都会失败：

 printf("%d", 1, 2);

但是，它只会打印“1”。

这里很多人都提出了cdecl、pascal和__stdcall调用约定。然而，这些都不是标准的一部分，而是某些实现的所有功能。这让我们回到我的第一句话。

Answer 2

这取决于所使用的调用约定。使用cdecl，调用者按从右到左的顺序将参数压入堆栈，然后被调用者通过偏移堆栈指针来访问它们。在这种情况下，调用太多参数不会破坏任何东西。

但是，如果您有从左到右的调用约定，那么事情就会崩溃。

Answer 3

使用 cdecl 调用约定，调用者负责清理堆栈，所以这是安全的。相比之下，pascal 调用约定使被调用者负责清理，因此这将是危险的。

Answer 4

在 C 中，这是违反约束的，因此会导致未定义的行为。

“如果表示被调用函数的表达式具有包含原型的类型，则参数的数量应与参数的数量一致。” （C99，第 6.5.2.2 条）

也就是说，实际上它主要取决于底层的调用约定。

Answer 5

至少在C和C++中它不会造成任何伤害。参数从右向左推送，被调用者负责堆栈清理。

但是，除非您使用可变参数或强制转换函数类型，否则编译器不会让您执行此操作。例如：

#include <stdio.h>

static void foo (int a, int b, int c, int d, int e, int f, int g)
{
    printf ("A:%d B:%d C:%d D:%d E:%d F:%d G:%d \n",
            a, b, c, d, e, f, g);
}

int main ()
{
    typedef void (*bad_foo) (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int);
    foo (1, 2, 3, 4, 5, 6, 7);
    bad_foo f = (bad_foo) (&foo);
    f (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17);
}

如果您查看汇编代码，所有参数都会被推入寄存器，但多余的参数会被忽略。

Answer 6

此类代码违反了单一定义规则（好吧，C 无论如何都相当于它......）它是否有效完全取决于平台。

特别是在 x86 上，如果函数被声明为 __cdecl，那么它将起作用，因为调用者会清理堆栈，但如果它是 __stdcall（大多数 Win32 函数都是如此），被调用者清理堆栈，在这种情况下会清理错误（因为它有太多参数）。因此，这取决于所使用的外部函数的调用约定。

我不明白你为什么想要这样做。

Answer 7

如果我做对了，这可能会导致你的程序从内存中执行随机代码。当调用函数时，一些值，包括返回地址（函数完成时程序将跳回的位置）被压入堆栈。之后，函数参数（x，y，z）被压入堆栈，程序跳转到函数的入口点。然后，该函数将从堆栈中弹出参数 (x, y)，执行某些操作，然后从堆栈中弹出返回地址（在本例中为 z，这是错误的）并跳回该地址。

这是堆栈详细信息的一个很好的描述： http://www.tenouk.com/Bufferoverflowc/Bufferoverflow2a .html