是不是只有编译的时候才知道程序写了错误?有没有在未编译的时候就让机器帮你检查错误的工具呢?
答案是:有!!
splint工具.用一个最简单的HELLO WORLD来表述:
=====================================
int main(void)
{
print("hello world\n", s);
return
}
</div>
-----------------------------------------------------
casio$ splint -strict foo.c
Splint 3.1.1 --- 03 Nov 2006
foo.c: (in function main)
foo.c:5:2: Unrecognized identifier: print <-------找到print不是printf
Identifier used in code has not been declared. (Use -unrecog to inhibit
warning)
foo.c:5:25: Unrecognized identifier: s <-------未定义变量s
foo.c:5:2: Statement has no effect (possible undected modification through call
to unconstrained function print): print("hello wor... <---------不存在prinf函数
Statement has no visible effect --- no values are modified. It may modify
something through a call to an unconstrained function. (Use -noeffectuncon to
inhibit warning)
foo.c:7:2: Parse Error. (For help on parse errors, see splint -help <------对应return语法错误
parseerrors.)
*** Cannot continue.
=============================================
cxref
cxref程序分析C源代码并且生成一个交叉引用。他显示了每一个符号在程序中何处被提到。他使用标记星号的每一个符号定义位置生成一个排序列表，如下所示：
SYMBOL FILE FUNCTION LINE
BASENID prog.c — *12 *96 124 126 146 156 166
BINSIZE prog.c — *30 197 198 199 206
BUFMAX prog.c — *44 45 90
BUFSIZ /usr/include/stdio.h — *4
EOF /usr/include/stdio.h — *27
argc prog.c — 36
prog.c main *37 61 81
argv prog.c — 36
prog.c main *38 61
calldata prog.c — *5
prog.c main 64 188
calls prog.c — *19
prog.c main 54
在作者的机子上，前面的输入在程序的源码目录中使用下面的命令来生成的：
$ cxref *.c *.h
但是实际的语法因为版本的不同而不同。查看我们系统的文档或是man手册可以得到更多的信息。
cflow <使用时输入cflow *.c就可以了.可以马上搞清除什么函数调用了什么.>
cflow程序会输出一个函数调用树，这是一个显示函数调用关系的图表。这对于查看程序结构来了解他是如何操作的以及了解对于一个函数有哪些影响是十分有用的。一些版本的cflow可以同时作用于目标文件与源代码。查看手册页我们可以了解更为详细的操作。
下面是由一个cflow版本(cflow-2.0)所获得的例子输出，这个版本的cflow版本是由Marty Leisner维护的，并且可以网上得到。
1 file_ungetc {prcc.c 997}
2 main {prcc.c 70}
3 getopt {}
4 show_all_lists {prcc.c 1070}
5 display_list {prcc.c 1056}
6 printf {}
7 exit {}
8 exit {}
9 usage {prcc.c 59}
10 fprintf {}
11 exit {}
从这个输出中我们可以看到main函数调用show_all_lists，而show_all_lists调用display_list，display_list本身调用printf。
这个版本cflow的一个选项就是-i，这会生成一个反转的流程图。对于每一个函数，cflow列出调用他的其他函数。这听起来有些复杂，但是实际上并不是这样。下面是一个例子。
19 display_list {prcc.c 1056}
20 show_all_lists {prcc.c 1070}
21 exit {}
22 main {prcc.c 70}
23 show_all_lists {prcc.c 1070}
24 usage {prcc.c 59}
...
74 printf {}
75 display_list {prcc.c 1056}
76 maketag {prcc.c 487}
77 show_all_lists {prcc.c 1070}
78 main {prcc.c 70}
...
99 usage {prcc.c 59}
100 main {prcc.c 70}
例如，这告诉我们调用exit的函数有main，show_all_lists与usage。
使用prof/gprof执行性能测试
当我们试着追踪一个程序的性能问题时一个十分有用的技术就是执行性能测试(execution profiling)。通常被特殊的编译器选项以及辅助程序所支持，一个程序的性能显示他在哪里花费时间。
prof程序（以及其GNU版本gprof）会由性能测试程序运行时所生成的执行追踪文件中输出报告。一个可执行的性能测试是由指定-p选项（对prof）或是-pg选项（对gprof）所生成的：
$ cc -pg -o program program.c
这个程序是使用一个特殊版本的C库进行链接的并且被修改来包含监视代码。对于不同的系统结果也许不同，但是通常是由安排频繁被中断的程序以及记录执行位置来做到的。监视数据被写入当前目录中的一个文件，mon.out（对于gprof为gmon.out）。
$ ./program
$ ls -ls
2 -rw-r--r-- 1 neil users 1294 Feb 4 11:48 gmon.out
然后用命令:gprof ./program可以查看到下面的报告
prof/gprof程序读取这些监视数据并且生成一个报告。查看其手册页可以详细了解其程序选项。下面以gprof输出作为一个例子：
cumulative self self total
time seconds seconds calls ms/call ms/call name
18.5 0.10 0.10 8664 0.01 0.03 _doscan [4]
18.5 0.20 0.10 mcount (60)
14.8 0.28 0.08 43320 0.00 0.00 _number [5]
9.3 0.33 0.05 8664 0.01 0.01 _format_arg [6]
7.4 0.37 0.04 112632 0.00 0.00 _ungetc [8]
7.4 0.41 0.04 8757 0.00 0.00 _memccpy [9]
7.4 0.45 0.04 1 40.00 390.02 _main [2]
3.7 0.47 0.02 53 0.38 0.38 _read [12]
3.7 0.49 0.02 w4str [10]
1.9 0.50 0.01 26034 0.00 0.00 _strlen [16]
1.9 0.51 0.01 8664 0.00 0.00 strncmp [17]
内存调试
富含bug而且难于跟踪调试的一个区域就是动态内存分配。如果我们编译一个使用malloc与free来分配内存的程序，很重要的一点就是我们要跟踪我们所分配的内存块，并且保证不要使用已经释放的内存块。
通常，内存是由malloc分配并且赋给一个指针变量的。如果指针变量被修改了，而又没有其他的指针来指向这个内存块，他就会变为不可访问的内存块。这就是一个内存泄露，而且会使得我们程序尺寸变大。如果我们泄露了大量的内存，那么我们的系统就会变慢并且会最终用尽内存。
如 果我们在超出一个分配的内存块的结束部分（或是在一个内存块的开始部分）写入数据，我们很有可能会破坏malloc库来跟踪分配所用的数据结构。在这种情 况下，在将来的某个时刻，调用malloc，或者甚至是free，就会引起段错误，而我们的程序就会崩溃。跟踪错误发生的精确点是非常困难的，因为很可能 他在引起崩溃的事件发生以前很一段时间就已经发生了。
不必奇怪的是，有一些工具，商业或是自由的，可以有助于处理这两种问题类型。例如，有许多不同的malloc与free版本，其中的一些包含额外的代码在分配与回收上进行检测尝试检测一个内存块被释放两次或是其他一些滥用类型的情况。
ElectricFence
ElectricFence 库是由Bruce Perens开发的，并且在一些Linux发行版本中作为一个可选的组件来提供，例如RedHat，而且已经可以在网络上获得。他尝试使用Linux的虚 拟内存工具来保护malloc与free所使用的内存，从而在内存被破坏时终止程序。
试验－－ElectricFence
下面的程序，efence.c，使用malloc分配一个内存块，然后在超出块结束处写入数据。让我们看一下会发生什么情况。
$ cc -o efence efence.c
$ ./efence
$
然而，如果我们使用ElectricFence库，libefence.a来链接这个程序，我们就会得到一个即时的响应。
$ cc -o efence efence.c -lefence
$ ./efence
Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <bruce@perens.com>
Segmentation fault
$
在调试器下运行可以定位这个问题：
$ cc -g -o efence efence.c -lefence
$ gdb efence
(gdb) run
Starting program: /home/neil/BLP3/chapter10/efence
[New Thread 1024 (LWP 1869)]
Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <bruce@perens.com>
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 18