最近多个分支往基线合并,不同分支上基于不同平台的硬件抽象层提供给应用层的接口有变化,函数参数个数的变化是其中一个大类。
这带来的一个问题,实参和形参个数不一致,能编译通过,且有些情况没有警告,并且能链接通过,但是运行时会产生严重的运行时错误。
事实上,实参和形参个数不一致的问题,编译器是做了检查的,虽然这个检查机制不太完美。
在存在前置声明的情况下,编译器是会做实参和形参个数的检查的,建立两个文件如下图所示:
编译器会报错如下:
现在,让我们注掉对foo函数的前置声明,如下:
编译可以通过
然后,将注掉的代码打开,但是将去掉一个形参,入校所示:
同样可以编译通过。
通过以上的demo,可以推测出编译器只有在能拿到前置声明的时候才会同时也是才有办法进行参数检查,事实也确实如此。
因为在编译期,如果没有前置声明,编译器根本就不知道函数原型是什么,更别提什么检查。
正常来说编译器不检查,那么链接器总该检查吧,但是偏偏C语言对函数符号的判断以函数名作为符号的识别依据(C语言不支持重载)。
对于linker来说,在遍历全局符号表的时候,找到一个同名函数,就会将调用位置重定位到相应位置。
因为在开发工具上没有很好的对此类潜在问题有很好的检查机制,所以在使用C语言的时候,这个地方还是需要特别注意的。