以下程序在 g++ 中完美编译，没有错误或警告(即使使用 -Wall)，但立即崩溃。

#include <cstdio>

int stuff(void)
{
    puts("hello there.");
    return 0;
}


int (*main)(void) = stuff;

这是一个(显然是被严重误导的)尝试运行 C++ 程序而不明确声明 main 为函数的尝试。我打算通过将程序绑定(bind)到符号 main 来执行 stuff。我对这个编译感到非常惊讶，但是为什么编译后它会失败呢？我查看了生成的程序集，但我完全不了解它。

我完全知道有很多 restrictions关于如何定义/使用 main ，但我不清楚我的程序如何破坏它们中的任何一个。我没有重载 main 或在我的程序中调用它......那么通过这种方式定义 main 我到底违反了什么规则？

注意:这不是我试图在实际代码中做的事情。这实际上是尝试 write Haskell in C++ 的开始。 .

最佳答案

在 main 之前运行的代码中，有如下内容:

extern "C" int main(int argc, char **argv);

您的代码的问题在于，如果您有一个名为 main 的函数指针，它与函数不同(与 Haskell 相比，函数和函数指针几乎可互换 - 至少在我对 Haskell 的 0.1% 知识的情况下)。

虽然编译器会很乐意接受:

int (*func)()  = ...;

int x = func();

作为对函数指针func的有效调用。但是，当编译器生成代码来调用 func 时，它实际上以不同的方式执行此操作[尽管标准没有说明应该如何执行此操作，并且实际上在不同的处理器架构上有所不同它加载指针变量中的值，然后调用此内容]。

当你有:

int func() { ... }

int x = func();

对 func 的调用只是引用 func 本身的地址，然后调用它。

因此，假设您的代码确实编译，main 之前的启动代码将调用您的变量 main 的地址，而不是间接读取 main 中的值 然后调用它。在现代系统中，这将导致段错误，因为 main 存在于不可执行的数据段中，但在旧操作系统中，它很可能由于 main 不包含而崩溃真实的代码(但在这种情况下它可能会在它跌倒之前执行一些指令 - 在昏暗而遥远的过去，我不小心运行了各种难以发现原因的“垃圾”......)

但由于 main 是一个“特殊”函数，编译器也可能会说“不，你不能这样做”。

它曾经工作，很多年前这样做:

char main[] = { 0xXX, 0xYY, 0xZZ ... }; 

但同样，这在现代操作系统中不起作用，因为 main 最终出现在数据部分中，并且在该部分中不可执行。

编辑:在实际测试发布的代码之后，至少在我的 64 位 Linux 上，代码实际上可以编译，但不出所料，当它尝试执行 main 时会崩溃。

在 GDB 中运行会给出:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000600950 in main ()
(gdb) bt
#0  0x0000000000600950 in main ()
(gdb) disass
Dump of assembler code for function main:
=> 0x0000000000600950 <+0>: and    %al,0x40(%rip)        # 0x600996
   0x0000000000600956 <+6>: add    %al,(%rax)
End of assembler dump.
(gdb) disass stuff
Dump of assembler code for function stuff():
   0x0000000000400520 <+0>: push   %rbp
   0x0000000000400521 <+1>: mov    %rsp,%rbp
   0x0000000000400524 <+4>: sub    $0x10,%rsp
   0x0000000000400528 <+8>: lea    0x400648,%rdi
   0x0000000000400530 <+16>:    callq  0x400410 <puts@plt>
   0x0000000000400535 <+21>:    mov    $0x0,%ecx
   0x000000000040053a <+26>:    mov    %eax,-0x4(%rbp)
   0x000000000040053d <+29>:    mov    %ecx,%eax
   0x000000000040053f <+31>:    add    $0x10,%rsp
   0x0000000000400543 <+35>:    pop    %rbp
   0x0000000000400544 <+36>:    retq   
End of assembler dump.
(gdb) x main
0x400520 <stuff()>: 0xe5894855
(gdb) p main
$1 = (int (*)(void)) 0x400520 <stuff()>
(gdb) 

所以，我们可以看到 main 并不是一个真正的函数，它是一个包含指向 stuff 的指针的变量。启动代码调用 main 就好像它是一个函数，但它无法执行那里的指令(因为它是数据，并且数据设置了“不执行”位 - 不是你可以在这里看到，但我知道它是这样工作的)。

编辑2:

检查 dmesg 显示:

a.out[7035]: 段错误在 600950 ip 0000000000600950 sp 00007fff4e7cb928 错误 15 in a.out[600000+1000]

换句话说，段错误会随着 main 的执行而立即发生——因为它是不可执行的。

编辑3:

好的，所以它比这稍微复杂一些(至少在我的 C 运行时库中)，因为调用 main 的代码是一个函数，它将指向 main 的指针作为参数，并通过指针调用它。然而，这并没有改变这样一个事实，即当编译器构建代码时，它产生的间接级别比它需要的要少，并尝试执行名为 main 的变量而不是变量所在的函数指着。

在 GDB 中列出 __libc_start_main:

87  STATIC int
88  LIBC_START_MAIN (int (*main) (int, char **, char ** MAIN_AUXVEC_DECL),
89           int argc, char *__unbounded *__unbounded ubp_av,
90  #ifdef LIBC_START_MAIN_AUXVEC_ARG
91           ElfW(auxv_t) *__unbounded auxvec,
92  #endif

此时打印main给了我们一个指向0x600950的函数指针，也就是名为main的变量(和我上面反汇编的一样)

(gdb) p main
$1 = (int (*)(int, char **, char **)) 0x600950 <main>

请注意，这是一个不同的变量 main 与问题中发布的源中称为 main 的变量不同。

关于c++ - 为什么这个将 main 定义为函数指针的程序会失败？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22675528/