我不明白为什么获取一个变量的地址很好，而另一个变量会让我0xD然后由于在无效地址写入值而崩溃(0xD在r.thefn(0);中)。
这是显示两个没有相似地址的变量的输出。以下是 GDB 显示的内容和程序集输出。我的 x86 程序集不是很好(我从未编写过 x86 程序集)。我不知道它是否显示了足够的信息，但是如果我没有，您能告诉我调试它还需要什么吗？为什么一个变量0xBF8BAF1C而另一个变量0xD？C++和汇编代码如下，但在上面的 gist 链接中格式更好。
有一个static_assert强制字符串成为 POD，这意味着没有非竞争对手的构造函数。它使用C++生成的默认构造函数。它也在堆栈上，这意味着如果new过载，它不会影响它。&没有重载，但在调用函数的前两次时看起来也正确。
什么可能会影响r地址？我可以看到变量varme的地址在第二次和第三次调用时是相同的，但第三次r神奇地不同。
这使用 Visual C++(2012 工作)，g++ 4.6.2 编译和运行，在使用 g++ 3.7、3.6.3 和 Clang 3.0 的 Linux (Ubuntu) 上失败。
sanity check 1 0xbf8bb4cc
sanity check 2 0xbf8bb4cc 0xbf8bb538
sanity check 3 0xbf8bb4cc 0xbf8bb538
this 0xbf8bb538
sanity check 1 0xbf8baf1c
sanity check 2 0xbf8baf1c 0xbf8baf40
sanity check 3 0xbf8baf1c 0xbf8baf40
this 0xbf8baf40
sanity check 1 0xbf8baf1c
sanity check 2 0xbf8baf1c 0xd
sanity check 3 0xbf8baf1c 0xd
this 0xd
这是代码：一个额外的注意事项是字符串上有一个static_assert，它强制它是一个 POD，这意味着没有非默认构造函数。我检查了操作员&没有过载。
static int aa=0;
aa++;
int varme;
printf("sanity check 1 %pn", &varme);
String r;
printf("sanity check 2 %p %pn", &varme, &r);
//auto v=anotherfn(sz);
printf("sanity check 3 %p %pn", &varme, &r);
//printf("callingfn=%s,%d %p %pn", sz,aa, v, &r);
r.thefn(0);
return r;
¦0x8084101 <callingfn(char const*)+1> mov %esp,%ebp ¦
¦0x8084103 <callingfn(char const*)+3> push %esi ¦
¦0x8084104 <callingfn(char const*)+4> sub $0x34,%esp ¦
¦0x8084107 <callingfn(char const*)+7> mov 0xc(%ebp),%eax ¦
¦0x808410a <callingfn(char const*)+10> mov 0x8(%ebp),%ecx ¦
¦0x808410d <callingfn(char const*)+13> mov %eax,-0x8(%ebp) ¦
¦0x8084110 <callingfn(char const*)+16> mov 0x81bc894,%eax ¦
¦0x8084115 <callingfn(char const*)+21> lea 0x1(%eax),%eax ¦
¦0x8084118 <callingfn(char const*)+24> mov %eax,0x81bc894 ¦
¦0x808411d <callingfn(char const*)+29> lea -0xc(%ebp),%eax ¦
¦0x8084120 <callingfn(char const*)+32> mov %esp,%edx ¦
¦0x8084122 <callingfn(char const*)+34> mov %eax,0x4(%edx) ¦
¦0x8084125 <callingfn(char const*)+37> movl $0x812ee78,(%edx) ¦
¦0x808412b <callingfn(char const*)+43> mov %ecx,-0x10(%ebp) ¦
¦0x808412e <callingfn(char const*)+46> mov %eax,-0x14(%ebp) ¦
¦0x8084131 <callingfn(char const*)+49> call 0x8049a90 <printf@plt> ¦
¦0x8084136 <callingfn(char const*)+54> mov %esp,%ecx ¦
¦0x8084138 <callingfn(char const*)+56> mov -0x10(%ebp),%edx ¦
¦0x808413b <callingfn(char const*)+59> mov %edx,0x8(%ecx) ¦
¦0x808413e <callingfn(char const*)+62> mov -0x14(%ebp),%esi ¦
¦0x8084141 <callingfn(char const*)+65> mov %esi,0x4(%ecx) ¦
¦0x8084144 <callingfn(char const*)+68> movl $0x812ee8b,(%ecx) ¦
¦0x808414a <callingfn(char const*)+74> mov %eax,-0x18(%ebp) ¦
¦0x808414d <callingfn(char const*)+77> call 0x8049a90 <printf@plt> ¦
¦0x8084152 <callingfn(char const*)+82> mov %esp,%ecx ¦
¦0x8084154 <callingfn(char const*)+84> mov -0x10(%ebp),%edx ¦
¦0x8084157 <callingfn(char const*)+87> mov %edx,0x8(%ecx) ¦
¦0x808415a <callingfn(char const*)+90> mov -0x14(%ebp),%esi ¦
¦0x808415d <callingfn(char const*)+93> mov %esi,0x4(%ecx) ¦
¦0x8084160 <callingfn(char const*)+96> movl $0x812eea1,(%ecx) ¦
¦0x8084166 <callingfn(char const*)+102> mov %eax,-0x1c(%ebp) ¦
¦0x8084169 <callingfn(char const*)+105> call 0x8049a90 <printf@plt> ¦
¦
¦0x8084169 <callingfn(char const*)+105> call 0x8049a90 <printf@plt> ¦
¦0x808416e <callingfn(char const*)+110> mov %esp,%ecx ¦
¦0x8084170 <callingfn(char const*)+112> mov -0x10(%ebp),%edx ¦
¦0x8084173 <callingfn(char const*)+115> mov %edx,(%ecx) ¦
¦0x8084175 <callingfn(char const*)+117> movl $0x0,0x4(%ecx) ¦
¦0x808417c <callingfn(char const*)+124> mov %eax,-0x20(%ebp) ¦
¦0x808417f <callingfn(char const*)+127> call 0x8056d00 <SomeClass<blah>::thefn(blah*)> ¦
>¦0x8084184 <callingfn(char const*)+132> add $0x34,%esp ¦
¦0x8084187 <callingfn(char const*)+135> pop %esi ¦
¦0x8084188 <callingfn(char const*)+136> pop %ebp ¦
¦0x8084189 <callingfn(char const*)+137> ret $0x4 ¦
¦0x808418c nopl 0x0(%eax)
设置：
String定义为：
struct String {
void *p;
#ifdef __cplusplus
/* Operators to help with comparing, etc. */
/* No additional data members */
void thefn(int arg); /* Return/argument type not relevant */
#endif
};
并包括用于验证sizeof(String) == sizeof(void *)和结构的 POD 性的断言。
这部分最初在问题中没有提到：调用此函数的函数向其调用方返回相同的String对象，但它是从外部 C 代码调用的，其中调用方期望一个简单的void *而不是String。作者的期望是这应该有效，因为返回值的大小和布局是相同的。
问题：
C++编译器在此函数中使用了命名的返回值优化(NRVO)。函数签名从
String fn(char const *);
自
void fn(char const *, String *);
这在反汇编中可见，在反汇编之前读取ebp+0xC，并且无需花费任何精力将有意义的结果放入 EAX。ret 0x4部分有点奇怪，因为它意味着只有一个参数从堆栈中清除，但显然这就是 GCC/Clang 选择通过让调用方清除附加参数来实现这一点的方式。
据推测，在调用方函数中应用了相同的优化。但是 C 编译器认为没有理由应用这种优化(毕竟，它期望结果是一个void*，而不是一个结构)，并且期望返回值像任何指针大小的结果一样传递。
结果：
- C 代码只将一个参数传递到C++代码中，该代码需要两个参数，堆栈顶部的垃圾被解释为第二个参数。
- C++代码不会生成有意义的返回值，而 C 代码希望找到一个返回值。
解决方案：
修复的第一步显然是确保 C 代码期望与C++代码相同的返回值，即结构而不是指针。
但是，我认为没有办法控制是否应用 NRVO，所以我怀疑即使使用正确的返回类型，鉴于结构的小尺寸，代码的两端仍然有可能不一致地应用此优化。我也不知道extern "C"是否会对它产生任何影响。
(这个回答总结了评论中所说的内容，并有一些猜测来填补空白)