为什么g++？链接器警告此不一致的函数声明？

Question

这是在 Debian scrape 上使用 g++ 4.4 和 g++ 4.7 进行测试的。考虑两个 C++ 源文件。

################
foo.cc
#################
#include <string>
using std::string;

int foo(void)
{
  return 0;
}

#################
bar.cc
#################
#include <string>
using std::string;

//int foo(void);
string foo(void);

int main(void)
{
  foo();
  return 0;
}
##################

如果我编译并运行它，可以预见会出现问题。我正在使用 scons。

################################
SConstruct
################################
#!/usr/bin/python


env = Environment(
    CXX="g++-4.7",
    CXXFLAGS="-Wall -Werror",
    #CXX="g++",
    #CXXFLAGS="-Wall -Werror",
    )

env.Program(target='debug', source=["foo.cc", "bar.cc"])
#################################

编译并运行...

$ scons

g++-4.7 -o bar.o -c -Wall -Werror bar.cc
g++-4.7 -o foo.o -c -Wall -Werror foo.cc
g++-4.7 -o debug foo.o bar.o

$ ./debug 

*** glibc detected *** ./debug: free(): invalid pointer: 0xbff53b8c ***
======= Backtrace: =========
/lib/i686/cmov/libc.so.6(+0x6b381)[0xb7684381]
/lib/i686/cmov/libc.so.6(+0x6cbd8)[0xb7685bd8]
/lib/i686/cmov/libc.so.6(cfree+0x6d)[0xb7688cbd]
/usr/lib/libstdc++.so.6(_ZdlPv+0x1f)[0xb7856c5f]
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb762fca6]
./debug[0x8048461]
======= Memory map: ========
08048000-08049000 r-xp 00000000 fd:10 7602195    /home/faheem/corrmodel/linker/debug
08049000-0804a000 rw-p 00000000 fd:10 7602195    /home/faheem/corrmodel/linker/debug
09ae0000-09b01000 rw-p 00000000 00:00 0          [heap]
b7617000-b7619000 rw-p 00000000 00:00 0 
b7619000-b7759000 r-xp 00000000 fd:00 1180005    /lib/i686/cmov/libc-2.11.3.so
b7759000-b775a000 ---p 00140000 fd:00 1180005    /lib/i686/cmov/libc-2.11.3.so
b775a000-b775c000 r--p 00140000 fd:00 1180005    /lib/i686/cmov/libc-2.11.3.so
b775c000-b775d000 rw-p 00142000 fd:00 1180005    /lib/i686/cmov/libc-2.11.3.so
b775d000-b7760000 rw-p 00000000 00:00 0 
b7760000-b777c000 r-xp 00000000 fd:00 4653173    /lib/libgcc_s.so.1
b777c000-b777d000 rw-p 0001c000 fd:00 4653173    /lib/libgcc_s.so.1
b777d000-b777e000 rw-p 00000000 00:00 0 
b777e000-b77a2000 r-xp 00000000 fd:00 1179967    /lib/i686/cmov/libm-2.11.3.so
b77a2000-b77a3000 r--p 00023000 fd:00 1179967    /lib/i686/cmov/libm-2.11.3.so
b77a3000-b77a4000 rw-p 00024000 fd:00 1179967    /lib/i686/cmov/libm-2.11.3.so
b77a4000-b7889000 r-xp 00000000 fd:00 2484736    /usr/lib/libstdc++.so.6.0.17
b7889000-b788d000 r--p 000e4000 fd:00 2484736    /usr/lib/libstdc++.so.6.0.17
b788d000-b788e000 rw-p 000e8000 fd:00 2484736    /usr/lib/libstdc++.so.6.0.17
b788e000-b7895000 rw-p 00000000 00:00 0 
b78ba000-b78bc000 rw-p 00000000 00:00 0 
b78bc000-b78bd000 r-xp 00000000 00:00 0          [vdso]
b78bd000-b78d8000 r-xp 00000000 fd:00 639026     /lib/ld-2.11.3.so
b78d8000-b78d9000 r--p 0001b000 fd:00 639026     /lib/ld-2.11.3.so
b78d9000-b78da000 rw-p 0001c000 fd:00 639026     /lib/ld-2.11.3.so
bff41000-bff56000 rw-p 00000000 00:00 0          [stack]
Aborted

Eww。如果链接器警告 foo 正在以两种不同的方式声明，则可以避免这种情况。即使使用 -Wall 也没有。那么，是否有理由不这样做，是否有一些标志我可以打开以使其发出警告？提前致谢。

编辑：感谢您的所有答案。当存在冲突的函数定义时，链接器确实会发出警告，而不是像上面的示例中那样存在冲突的函数定义和声明。我不明白这种不同行为的原因。

Answer 1

C++ 链接器仅根据唯一标识所需来标识函数。

这是来自以下关于 C++ 链接器的深入文章。

...符号的名称用附加字符串修饰。
这称为名称修改。

标识符名称前需要修饰，因为 C++
支持命名空间。例如，可能会出现相同的函数名称
在不同的命名空间中多次表示不同的
每次实体。使链接器能够区分这些
实体每个标识符的名称前面都带有标记
代表其封闭的命名空间。

标识符名称后面的修饰是必需的，因为 C++ 允许
函数重载。同样，相同的函数名称可以表示
不同的标识符，仅在参数列表上有所不同。到
使链接器能够区分这些标记，它们代表
参数列表附加到标识符的名称后面。这
函数的返回类型被忽略，因为两个重载
函数不能仅在返回类型上有所不同。

因此，关键在于，应用于函数的名称修饰会忽略返回类型，因为重载函数不能因返回类型而异。因此链接器无法发现问题。

Answer 2

链接器仅作用于编译器所说的模块中定义的名称或模块引用（需要）的名称。 GCC 显然使用“Itanium C++ ABI”来修改函数名称（从 GCC 3 开始）。对于大多数函数，返回类型不会合并到重整名称中，因此链接器不考虑它：

安腾 C++ ABI

函数类型由它们的参数类型和可能的
结果类型。除了在 , 或 的外层类型
在 a 中以其他方式分隔的外部名称中
或函数编码，这些类型
由“F..E”对分隔。出于替代目的（参见
下面的压缩），带分隔符和不带分隔符的函数类型是
认为是相同的。

函数类型的修饰是否包括返回类型
取决于上下文和功能的性质。规则为
判断是否包含返回类型有：

• 模板函数（名称或类型）具有编码的返回类型，但下面列出的例外情况。
• 不作为函数名称修改的一部分出现的函数类型（例如参数、指针类型等）具有返回类型编码，但下面列出的例外情况。
• 非模板函数名称没有编码的返回类型。

上面(1)和(2)中提到的异常，返回
类型从不包括在内，是

• 构造函数。
• 析构函数。
• 转换运算符函数，例如operator int

通常，在C++ 中，当编译器执行名称查找（例如重载解析）时，不会考虑函数的返回类型。这可能是返回类型通常不包含在名称修改中的部分原因。我不知道是否有更强有力的理由不将返回类型合并到损坏的名称中。

Answer 3

这是拥有包含所有此类函数的本地项目头文件（可能是 foobar.h ）的最佳示例。这样编译器可以发现此类问题。

链接器从来没有打算识别这样的问题。必须给 Real Engineers™ 留下一些事情去做。 :-)

Answer 4

$ cat foo.cpp

#include <string>
using std::string;

int foo(void)
{
    return 0;
}

$ cat bar.cpp

#include <string>
using std::string;

//int foo(void);
string foo(void);

int main(void)
{
    foo();
    return 0;
}

$ g++ -c -o bar.o bar.cpp
$ g++ -c -o foo.o foo.cpp
$ g++ foo.o bar.o
$ ./a.out 
$ echo $?
0
$ g++ --version
g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1

无法重现。