我一直在尝试使用函数，发现参数的顺序在内存中被颠倒了。为什么会这样？
stack-test.cpp：
#include <stdio.h>
void test( int a, int b, int c ) {
printf("%p %p %p\n", &a, &b, &c);
printf("%d %d\n", *(&b - 1), *(&b + 1) );
}
int main() {
test(1,2,3);
return 0;
}
CLang：
$ clang++ stack-test.cpp && ./a.out
0x7fffb9bb816c 0x7fffb9bb8168 0x7fffb9bb8164
3 1
GCC：
$ g++ stack-test.cpp && ./a.out
0x7ffe0b983b3c 0x7ffe0b983b38 0x7ffe0b983b34
3 1
编辑：不是重复问题：计算顺序可能与内存布局不同，因此这是一个不同的问题。
...椭圆表示），参数通常从右到左推送或为它们保留堆栈空间。这通常被称为C调用约定(C calling convention) (1)。使用此约定和机器堆栈向内存下方增长的常见约定，第一个参数应该出现在最低地址处，与您的结果相反。000000000023FE30 000000000023FE38 000000000023FE40
当我使用32位的Visual C++ 2015编译您的程序时，会出现以下情况：
00BFFC5C 00BFFC60 00BFFC64
这两个结果都符合C调用约定，与您的结果相反。
因此可能的结论是，您的编译器默认使用非C调用约定，至少对于非变参函数如此。
您可以通过在形式参数列表末尾添加...进行测试。
1) C调用约定还包括调用者在函数返回时调整堆栈指针，但这在这里并不相关。
a和c的地址，它们将根本不会出现在堆栈上...（好吧，至少不会出现在该函数调用帧内的堆栈上，当然它们会出现在main函数的堆栈上） - Mats PeterssonC（和C++）标准未定义参数传递的顺序，或者它们在内存中应该如何组织。这取决于编译器开发人员（通常与操作系统开发人员合作）来想出适用于特定处理器架构的解决方案。
在大多数架构中，堆栈（和寄存器）用于将参数传递给函数，并且同样，在大多数C实现中，堆栈从“高到低”地址增长，传递的参数顺序为“左后右先”，因此如果我们有一个函数
void test( int a, int b, int c )
c, b, a
然而，当参数的值被传递到寄存器中，并且使用这些参数的代码正在获取这些参数的地址时，情况变得更加复杂 - 寄存器没有地址，因此您无法获取寄存器变量的地址。因此，编译器将生成一些代码在函数本地将地址存储在栈上[从中我们可以获得该值的地址]。这完全取决于编译器的决定，它以什么顺序执行此操作，我相信这就是您所看到的。
如果我们将您的代码通过clang编译，我们会看到：
define void @test(i32 %a, i32 %b, i32 %c) #0 {
entry:
%a.addr = alloca i32, align 4
%b.addr = alloca i32, align 4
%c.addr = alloca i32, align 4
store i32 %a, i32* %a.addr, align 4
store i32 %b, i32* %b.addr, align 4
store i32 %c, i32* %c.addr, align 4
%call = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([10 x i8], [10 x i8]* @.str, i32 0, i32 0), i32* %a.addr, i32* %b.addr, i32* %c.addr)
%add.ptr = getelementptr inbounds i32, i32* %b.addr, i64 -1
%0 = load i32, i32* %add.ptr, align 4
%add.ptr1 = getelementptr inbounds i32, i32* %b.addr, i64 1
%1 = load i32, i32* %add.ptr1, align 4
%call2 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([7 x i8], [7 x i8]* @.str.1, i32 0, i32 0), i32 %0, i32 %1)
ret void
}
虽然可能不是完全容易阅读的，但您可以看到测试函数的前几行：
%a.addr = alloca i32, align 4
%b.addr = alloca i32, align 4
%c.addr = alloca i32, align 4
store i32 %a, i32* %a.addr, align 4
store i32 %b, i32* %b.addr, align 4
store i32 %c, i32* %c.addr, align 4
这实际上是在堆栈上创建空间 (%alloca)，并将变量 a、b 和 c 存储到这些位置。
gcc 生成的汇编代码更难阅读，但您可以看到类似的操作：
subq $16, %rsp ; <-- "alloca" for 4 integers.
movl %edi, -4(%rbp) ; Store a, b and c.
movl %esi, -8(%rbp)
movl %edx, -12(%rbp)
leaq -12(%rbp), %rcx ; Take address of ...
leaq -8(%rbp), %rdx
leaq -4(%rbp), %rax
movq %rax, %rsi
movl $.LC0, %edi
movl $0, %eax
call printf ; Call printf.
C（和C++）代码使用处理器堆栈将参数传递给函数。
堆栈的操作方式取决于处理器。堆栈可以（理论上）向下或向上增长。因此，您的处理器正在定义地址增长或缩小。最后，不仅仅是处理器架构对此负责，还有用于在架构上运行的代码的调用约定。
调用约定规定了如何为一个特定的处理器架构在堆栈上放置参数。这些约定是必要的，以便来自不同编译器的库可以链接在一起。
基本上，对于您作为C用户而言，如果堆栈上的变量地址增长或缩小，通常没有区别。
细节：
ABI 定义了如何传递参数。
在您的示例中，由于 x86_64 ABI 默认使用 gcc 和 clang 在寄存器上传递参数(*)，因此没有为它们分配地址。
然后您引用这些参数，所以编译器被迫为这些变量分配本地存储空间，而该排序和内存布局也是特定于实现的。
谈论32位x86 Windows
简短回答：指向函数参数的指针不一定是指向实际函数调用时推入堆栈的指针，而可以是编译器重新定位变量的任何位置。
详细回答： 在将我的代码从bcc32（Embarcadero经典编译器）转换为CLANG时遇到了同样的问题。由MIDL编译器生成的RPC代码已经损坏，因为RPC函数参数翻译器通过获取第一个函数参数的指针来序列化参数，假设所有后续参数都会像Serialize(&a)一样跟随。
调试了BCC32和CLANG生成的cdecl函数调用：
BCC32：函数参数按正确顺序在堆栈上传递，然后在需要参数地址时直接给出堆栈地址。
CLANG：函数参数按正确顺序在堆栈上传递，但是在实际函数中，所有参数的副本都以堆栈相反的顺序在内存中创建，并且在需要函数参数地址时，直接给出内存地址，导致顺序颠倒。
*(&b-1)会导致未定义的行为。 - M.M