一个疏忽引发的思考

前几天写代码因为自己的疏忽导致一遍又一遍的Segmentation fault (core dumped)。该问题是因为strerror（errno）返回的指针指向非法的内存导致程序打印错误时崩溃。

　　尝试数次无果，为了进度。简单粗暴的换成了perror(str)。今天忙里偷闲，定位到了问题做个记录和分享。

　　所有的坑，都是自己挖的。开始正题。

#include<stdio.h>
#include<errno.h>
//#include<string.h>
int main()
{
    char *perr = NULL;
    errno = 14;
    perr = strerror(errno);
    puts(perr);
    return 0;
}

先看代码，上述我屏蔽了#include<string.h>。如我所料，编译通过（其实有warn已经告诉你有问题了），运行崩溃了。warn如下：

　　

　　然后加上#include<string.h>程序完美编译，完美成功执行。为什么呢？经过与人（CSDN某某某）讨论和浏览stackoverflow上的帖子，以及我最终使用gcc -E预编译  gcc -Wall的验证。

　　

　　我得到以下结论。

　　1.strerror（）函数声明在string.h头文件里（我以前以为是在errno.h里的，还是基本功不行啊）。

　　2.gcc编译时如果发现未定义的函数，它会认为该函数是定义在其他源文件中的，所以编译是通过的。

　　但是因为编译器看不见函数原型，所以它认为函数返回值为int。在链接阶段，如果找到该函数则通过，找不到则报错。
    这里我做了个实验，如果函数原型在.o文件里链接后没有问题，连接器会修正返回值类型。但是如果链接的是.so文件，则返回值就是int。我也想不明白。

　　

　　揭晓答案吧！我的程序为什么会报错呢？这是一系列疏忽大意加基本功不扎实的恶果。

　　因为我没有包string.h。所以编译器看不见函数原型，默认函数返回值为int。并给出了wara：assignment makes pointer from integer without a cast（用一个int型给指针赋值而没有转换--英文不好）。显而易见，在64位系统中char*是64位的，int是32位。所以相当于我用32位的整型值当作地址赋值给了指针。所以指针指向非法内存。接着Segmentation fault (core dumped)就登场了。

　　系统中类型于strerror（）这种返回指针的函数都可能有类似问题，所以头文件该包的还是要包上。该注意的warn还是不容忽视啊。

　　文章到此已经结束，给个附录。64位系统 gcc编译器 各个数据类型长度表。