前几天写代码因为自己的疏忽导致一遍又一遍的Segmentation fault (core dumped)。该问题是因为strerror（errno）返回的指针指向非法的内存导致程序打印错误时崩溃。
尝试数次无果，为了进度。简单粗暴的换成了perror(str)。今天忙里偷闲，定位到了问题做个记录和分享。
所有的坑，都是自己挖的。开始正题。
1 #include<stdio.h>2 #include<errno.h>3 //#include<string.h>4 int main()5 {6 char *perr = NULL;7 errno = 14;8 perr = strerror(errno);9 puts(perr);10 return 0;11 }
先看代码，上述我屏蔽了#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编译器 各个数据类型长度表。
以上阐述由非权威人士撰写。如有大牛深谙其理，欢迎跟帖深入说明。
