本来晚上没事，也快10点了，有点无聊，就打开虚拟机，想把白天的程序完善一下。
结果，若来了大麻烦，本来11点睡觉的，也没睡成。
程序不难，把一些文本导入Sybase，再从里面取出来，生成另外一个文件。按照我的一贯风格，思路有了，就一气呵成。刷、刷、刷，写完了。make一下，出错了
***** Termination code 139 (bu21)
这是cc编译器终止编译的错误。晕倒，怎么回事！？
检查，复查，再尝试make，还是报错，程序里面用了两个Sybase的动态游标，感觉像是这里出了点问题。没辙，先取CU看看有没有同行遇到类似问题。搜索了一下论坛，还真有人遇到类似问题，他也定义了两个游标，编译报错了，但据他帖子里面的说法，更换一下目录再编译会解决问题。！？？，Too weird了一点吧？不管这么多，试试再说:
# mkdir yyy
# cp xxx yyy
这两行命令打出来，我暗自佩服我自己的忍耐力。然而失望来得也很快，编译仍然没通过。不过，这次我没用make，用的是cpre命令行，编译出错的时候居然core dumped。不会吧，这几千行代码有如此厉害么，把Sybase的cpre都弄趴了？看来问题比较严重。
重新排查代码，逐行去除所有潜在的漏洞，也许一个小小的漏洞就成了黑客帝国里的Smith了。
历经几十分钟磨难，终于找到问题。把 FILE* fp = NULL; 改成 FILE* fp;就行了。唉，Sybase，实在是不服不行。但我写了一个测试程序来验证是否真的这么写就会编译不过，cpre告诉我，我还不了解它，它一直以来最大的特点就是充满奇妙的错误，从而其乐无穷。所以，这个错误只是在我这个程序里的一个特例，在其他地方不一定是成立的。
注：本文是昨晚写的，但wordpress打不开，就先发到了space上。另外今天早上过来又有一个发现，以前没注意到，所有c的变量定义应该在ESQL/C前面，如果放到ESQL/C后面，编译也会出错。
