一个C语言的惨痛教训
一个c语言动态库开发的惨痛教训，作为警示，希望大家不要碰到这类问题。
背景
交代下背景，最近的一个项目，apache module开发，使用的是c语言。这个其实比较无奈，apache mod_dav.h中声明的dav_error结构体，其中一个字段就是const char *namespace，这不是鄙视C++吗？
虽然有方法可以绕过，搞成C++的，最后还是决定用c语言开发。
悲剧
悲剧就是这样发生的。
调试发现模块crash频繁，用gdb调试，结果让人迷惑，在pool上分配的地址竟然out of bound，诸如如下面的代码。
ptr = apr_psprintf(r->pool, "<lp%d:href>%s</lp%d:href>", ns, ptr, ns);
resp = apr_pcalloc(pool, sizeof(*resp));
resp->href = apr_pstrdup(pool, uri);
...
而且有时候程序crash时，发现函数的入栈参数明显有问题，参数错位。折腾了两天也没查出是什么原因。怀疑是pool被程序破坏了，但该pool上分配的其他地址都很正常，检查n+1编程序也没发现什么问题。搞的相当于郁闷。本来感到apr的内存分配系统还是挺不错的，不过现在想想，pool要是真的不小心被程序破坏了，那也是相当难以查出来的。
发现原因
按照pool破坏的思路折腾了几天，实在是没找到头绪。这个问题原因的发现还是听偶然的，就是仔细检查编译警告时，发现编译器对于apr_xxx的string系列操作函数发出警告：
warning: assignment makes pointer from integer without a cast
我算是比较粗心的，对编译错误一般不仔细看，发现这个警告要归功于我的一位可爱的同事
。
当时我看到这个警告就怀疑，是不是这个原因引起的crash。阴霍的天空无疑透出了一丝光亮。
相关.h文件没有包含导致编译器不认识这些库函数，如同编译warning所显示的那样：于是c语言就会把指针cast为int。由于编译机器是64位linux，如果把分配的地址空间cast到32位的int型数据，那么对于超过4G的地址空间来讲，这个结果就是一场灾难。
通常情况，如果函数没有定义，本来在运行时会报链接错误。但是这些是库函数，所以能够正常链接。
添加头文件，重新编译运行。程序不再crash。
十年被蛇咬。马上动手把所有的编译warning都修复掉。怕了...
教训
不要忽略编译warning
编译条件要严，像函数没有声明这种情况，应该设置为error，而非warning。我们的编译框架不够严格。