C语言中的隐式函数声明

1 什么是C语言的隐式函数声明

在C89中，函数在调用前不一定非要声明。如果没有声明，那么编译器会自动按照一种隐式声明的规则，为调用函数的C代码产生汇编代码。下面是一个例子：

int main(int argc, char** argv) {
    double x = any_name_function();
    return 0; 
}

单纯的编译上述源代码，并没有任何报错，只是在链接阶段因为找不到名为any_name_function的函数体而报错。

[smstong@centos192 test]$ gcc -c main.c
[smstong@centos192 test]$ gcc main.o
main.o: In function `main':
main.c:(.text+0x15): undefined reference to `any_name_function'
collect2: ld 返回 1

之所以编译不会报错，是因为C89规定，对于没有声明的函数，自动使用隐式声明。相当于变成了如下代码：

int any_name_function();
int main(int argc, char** argv)
{
    double x = any_name_function();
    return 0;
}

本文为转载；这里我再插入一段，原文中是没有的：

引用自 https://blog.csdn.net/frank_jb/article/details/85321460
那么函数声明到底有声明作用呢？
其实函数声明的作用是让编译器帮你检查函数调用时有没有错误。比如参数的数量是否正确，如果调用函数时候少传入一个参数，并且没有声明该函数，编译器无法知道你调用是否正确，只会提示一个警告。很多人会忽略警告，导致最后程序运行时出现异常。

为什么如果不声明函数，编译器发现不了错误？

编译器在编译过程中依次生成与源文件对应的可重定位目标文件（.o），每个源文件中调用的函数在链接前都是以符号的形式体现在.o文件中。在编译过程中不会去检查某个函数的形式，因为函数参数是通过寄存器和压栈来处理的，直接把函数翻译成符号，编译器是不知道关于函数参数的信息的，最后交给连接器把符号翻译成地址。所以链接的时候只要能找到对应得符号就不会报错。

从现代C语言的角度来说，任何标识符(除了goto的label以及main()的main)在使用之前都一定要声明，函数也是如此。
理论上这是必须的，但某些编译器为了迁就以前代码的一些写法放松了这个要求。所以还是应该写，尽管看起来貌似不是必须的。

较新的C规范（C99、C11）是不允许不声明直接用的。只是GCC默认还允许implicit function declaration功能。

Implicit function declarations in C. It should be considered an error.
But C is an ancient language, so it’s only a warning. Compiling with
Werror (gcc) fixes this problem. When C doesn’t find a declaration, it
assumes this implicit declaration: int f();, which means the function
can receive whatever you give it, and returns an integer. If this
happens to be close enough (and in case of printf, it is), then things
can work. In some cases (e.g. the function actually returns a pointer,
and pointers are larger than ints), it may cause real trouble. Note
that this was fixed in newer C standards (C99, C11). In these
standards, this is an error. However, gcc doesn’t implement these
standards by default, so you still get the warning.

2 带来的问题

2.1 隐式声明函数名称恰好在链接库中存在，但返回非int类型

前面给出的例子，并不会造成太大影响，因为在链接阶段很容易发现存在的问题。然而下面这个例子则会造成莫名的运行时错误。

#include <stdio.h>
int main(int argc, char** argv)
{
    double x = sqrt(1);
    printf("%lf", x);
    return 0;
}

gcc编译链接

[smstong@centos192 test]$ gcc -c main.c
main.c: 在函数‘main’中:
main.c:6: 警告：隐式声明与内建函数‘sqrt’不兼容
[smstong@centos192 test]$ gcc main.o

运行结果

1.000000

编译时会给出警告，提示隐式声明与内建函数’sqrt’不兼容。gcc编译器在编译时能够自动在常用库头文件（内建函数）中查找与隐式声明同名的函数，如果发现两者并不相同，则会按照内建函数的声明原型去生成调用代码。这往往也是程序员预期的想法。
上面的例子中隐式声明的函数原型为：

int sqrt(int);

而对应的同名内建函数原型为：

double sqrt(double);

最终编译器按照内建函数原型进行了编译，达到了预期效果。然而gcc编译器的这种行为并不是C语言的规范，并不是所有的编译器实现都有这样的功能。同样的源码在VC++2015下编译运行的结果却是：

VC++编译

warning C4013: “sqrt”未定义；假设外部返回 int

运行结果

2884223.000000

显然，VC++编译器没有没有所谓的“内建函数”，只是简单的按照隐式声明的原型，生成调用sqrt函数的代码。由于返回类型和参数类型的不同，导致错误的函数调用方式，产生莫名奇妙的运行时错误。

对着这种情况，由于返回类型的不同，两种编译器都可以给出警告信息，至少能引起程序员的注意。而下面这种情况，则更加隐蔽。

2.2 隐式声明函数名称恰好在链接库中存在，且返回int类型

测试代码如下：

#include <stdio.h>

int main(int argc, char** argv)
{
    int x = abs(-1);
    printf("%d", x);
    return 0;
}

此时，由于隐式声明的函数原型与gcc的内建函数原型完全相同，所以gcc不会给出任何警告，结果也是正确的。
而VC++则仍然会给出警告：warning C4013: “abs”未定义；假设外部返回 int。

无论如何，隐式声明的函数原型与库函数完全相同，所以链接运行都是没有问题的。

下面，稍微改动一下代码：

#include <stdio.h>

int main(int argc, char** argv)
{
    int x = abs(-1,2,3,4);
    printf("%d", x);
    return 0;
}

gcc编译链接

[smstong@centos192 test]$ gcc -c main.c
[smstong@centos192 test]$ gcc main.o

没有任何警告，可见，gcc的内建函数机制并不关心函数的参数，只是关心函数的返回值。

vc++编译链接

warning C4013: “abs”未定义；假设外部返回 int

虽然这个例子的运行结果都是正确的，但是这种正确是“碰巧”的，因为额外的函数参数并没有影响到结果。这种偶然正确是程序中要避免的。

3 编程中注意事项

C语言的隐式函数声明，给程序员带来了各种困惑，给程序的稳定性带来了非常坏的影响。不知道当初C语言设计者是如何考虑这个问题的？

• 为了避免这种影响，强烈建议程序员重视编译器给出的关于隐式声明的警告，及时通过包含必要的头文件来消除这种警告。*

对于gcc来说，前面给出的那个abs(-1,2,3,4)的特殊例子，编译器根本不会产生任何警告，只能靠程序员熟悉自己调用的每一个库函数了。

为了避免这种问题，在C语言的C99版本中，无论如何都会给出警告。如gcc使用C99编译上述代码。

gcc -std=c99编译

[smstong@centos192 test]$ gcc -c main.c -std=c99
main.c: 在函数‘main’中:
main.c:5: 警告：隐式声明函数‘abs’

而C++则更严格，直接抛弃了隐式函数声明，对于未声明函数的调用，将直接无法通过编译。

g++编译

[smstong@centos192 test]$ g++ main.c
main.c: In function ‘int main(int, char**)’:
main.c:5: 错误：‘abs’在此作用域中尚未声明

vc++编译（作为C++)

error C3861: “abs”: 找不到标识符

在函数强类型这一点上，C++确实比C更严格，更严谨。