C/C++语言的语法拥有其它语言所没有的灵活性，这种灵活性带来了代码效率的提升，但相应增加了代码中存在隐患的可能性。静态代码检查工具PC-Lint则偏重于代码的逻辑分析，它能够发现代码中潜在的错误，比如数组访问越界、内存泄漏、使用未初始化变量等。本文将介绍如何安装和配置PC-Lint代码检查工具以及如何将PC-Lint与常见的代码编辑软件集成。
1 引 言
2 PC-Lint介绍
3 PC-Lint的代码检查功能
3.1 强类型检查
3.2 变量值跟踪
3.3 赋值顺序检查
3.4 弱定义检查
3.5 格式检查
3.6 缩进检查
3.7 const变量检查
3.8 volatile变量检查
4 PC-Lint软件使用方法
4.1 安装与配置
4.2 PC-Lint与常用开发工具的集成（Visual C++,Source Insight,UEdit)
5 总结
参考文献
附录一 PC-Lint 重要文件说明
附录二 错误信息禁止选项说明
附录三 PC-Lint检测中的常见错误
C/C++语言的语法拥有其它语言所没有的灵活性，这种灵活性带来了代码效率的提升，但相应也使得代码编写具有很大的随意性，另外C/C++编译器不进行强制类型检查，也不做任何边界检查，这就增加了代码中存在隐患的可能性。如果能够在代码提交测试之前发现这些潜在的错误，就能够极大地减轻测试人员的压力，减少软件项目的除错成本，可是传统的C/C++编译器对此已经无能为力，这个任务只能由专用的代码检查工具完成。目前有很多C/C++静态代码检查工具，其中Logiscope RuleChecker和PC-Lint是目前应用比较广泛的两个工具。这两个检查工具各有特色，Logiscope RuleChecker倾向于代码编码规范的检查，比如代码缩进格式、case语句书写规范、函数声明和布尔表达式的编写规则等，而PC-Lint则偏重于代码的逻辑分析，它能够发现代码中潜在的错误，比如数组访问越界、内存泄漏、使用未初始化变量等。本文将介绍如何安装和配置PC-Lint代码检查工具以及将PC-Lint与常见的代码编辑软件，如Visual C++，Source Insight集成的方法，同时还将简要介绍一些PC-Lint常用的代码检查选项。
PC-Lint是GIMPEL SOFTWARE公司开发的C/C++软件代码静态分析工具，它的全称是PC-Lint/FlexeLint for C/C++，PC-Lint能够在Windows、MS-DOS和OS/2平台上使用，以二进制可执行文件的形式发布，而FlexeLint 运行于其它平台，以源代码的形式发布。PC-lint在全球拥有广泛的客户群，许多大型的软件开发组织都把PC-Lint检查作为代码走查的第一道工序。PC-Lint不仅能够对程序进行全局分析，识别没有被适当检验的数组下标，报告未被初始化的变量，警告使用空指针以及冗余的代码，还能够有效地帮你提出许多程序在空间利用、运行效率上的改进点。
通过下面的例子就可以看出PC-Lint工具的强大功能：
1：
2：char *report( int m, int n, char *p )
3：{
4： int result;
5： char *temp;
6： long nm;
7： int i, k, kk;
8： char name[11] = "Joe Jakeson";
9：
10： nm = n * m;
11： temp = p == "" ? "null" : p;
12： for( i = 0; i<m; I++ ) {
14： k++;
15： kk = i;
16： }
17：
18： if( k== 1 ) result = nm;
19： else if( kk > 0 ) result = 1;
20： else if( kk < 0 ) result = -1;
21：
22： if( m == result ) return( temp );
23： else return( name );
24：}
这是一段C代码，可以通过大多数常见的C语言编译器的检查，但是PC-Lint能够发现其中的错误和潜在的问题：第8行向name数组赋值时丢掉了结尾的nul字符，第10行的乘法精度会失准，即使考虑到long比int的字长更长，由于符号位的原因仍然会造成精度失准，第11行的比较有问题，第14行的变量k没有初始化，第15行的kk可能没有被初始化，第22行的result也有可能没有被初始化，第23行返回的是一个局部对象的地址。
随着C++语言的出现，C/C++编译器有了更严格的语法检查，但是仍然不能避免出现有BUG的程序。C++的类型检查依然不如Pascal那么严格。对于一个小程序，多数程序员都能够及时发现上面出现的错误，但是从一个拥有成千上万行代码的大型软件中找出这些瑕疵将是一项烦琐的工作，而且没有人可以保证能找出所有的这类问题。如果使用PC-Lint，只需通过一次简单的编译就可以检查出这些错误，这将节省了大量的开发时间。从某种意义上说。PC-Lint是一种更加严格的编译器，它除了可以检查出一般的语法错误外，还可以检查出那些虽然符合语法要求，但很可能是潜在的、不易发现的错误。
PC-Lint能够检查出很多语法错误和语法上正确的逻辑错误，PC-Lint为大部分错误消息都分配了一个错误号，编号小于1000的错误号是分配给C语言的，编号大于1000的错误号则用来说明C++的错误消息。表 1 列出了PC-Lint告警消息的详细分类：
|
表 1 列出了PC-Lint告警消息分类 |
|||
|
错误说明 |
C |
C++ |
告警级别 |
|
语法错误 |
1-199 |
1001-1199 |
1 |
|
内部错误 |
200-299 |
|
0 |
|
致命错误 |
300-399 |
|
0 |
|
告警 |
400-699 |
1400-1699 |
2 |
|
消息 |
700-800 |
1700-1899 |
3 |
|
可选信息 |
900-999 |
1900-1999 |
4 |
以C语言为例，其中的编号1-199指的是一般编译器也会产生的语法错误；编号200-299是PC-Lint程序内部的错误，这类错误不会出现在代码中的；编号300-399指的是由于内存限制等导致的系统致命错误。编号400-999中出现的提示信息，是根据隐藏代码问题的可能性进行分类的：其中编号400-699指的是被检查代码中很可能存在问题而产生的告警信息；编号700-899中出现的信息，产生错误的可能性相比告警信息来说级别要低，但仍然可能是因为代码问题导致的问题。编号900-999是可选信息，他们不会被默认检查，除非你在选项中指定检查他们。
PC-Lint/FelexLint提供了和许多编译器类似的告警级别设置选项-wLevel，它的告警级别分为以下几个级别，缺省告警级别为3级：
-w0 不产生信息（除了遇到致命的错误）
-w1 只生成错误信息 -- 没有告警信息和其它提示信息
-w2 只有错误和告警信息
-w3 生成错误、告警和其它提示信息（这是默认设置）
-w4 生成所有信息
PC-Lint/FelexLint还提供了用于处理函数库的头文件的告警级别设置选项-wlib(Level)，这个选项不会影响处理C/C++源代码模块的告警级别。它有和-wLevel相同的告警级别，缺省告警级别为3级：
-wlib(0) 不生成任何库信息
-wlib(1) 只生成错误信息（当处理库的源代码时）
-wlib(2) 生成错误和告警信息
-wlib(3) 生成错误、告警和其它信息（这是默认设置）
-wlib(4) 产生所有信息
PC-Lint的检查分很多种类，有强类型检查、变量值跟踪、语义信息、赋值顺序检查、弱定义检查、格式检查、缩进检查、const变量检查和volatile变量检查等等。对每一种检查类型，PC-Lint都有很多详细的选项，用以控制PC-Lint的检查效果。PC-Lint的选项有300多种，这些选项可以放在注释中（以注释的形式插入代码中），例如：
选项可以有多行
//lint option1 option2 ... optional commentary 选项仅为一行（适用于C++）
选项间要以空格分开，lint命令一定要小写，并且紧跟在 ((x) /0) 允许除数为0而不告警
下面将分别介绍PC-Lint常用的，也是比较重要的代码检查类型，并举例介绍了各个检查类型下可能出现的告警信息以及常用选项的用法：
3.1 强类型检查
强类型检查选项“-strong”和它的辅助（补充）选项“-index”可以对typedef定义的数据类型进行强类型检查，以保证只有相同类型之间的变量才能互相赋值，强类型检查选项strong的用法是：
-strong( flags[, name] ... )
strong选项必须在typedef定义类型之前打开，否则PC-Lint就不能识别typedef定义的数据类型，类型检查就会失效。flags参数可以是A、J、X、B、b、l和f，相应的解释和弱化字符在表 2 中列出：
|
表 2 强类型检查strong选项和参数表 |
|
|
A |
对强类型变量赋值时进行类型检查，这些赋值语句包括：直接赋值、返回值、参数传递、初始化 。 |
|
X |
当把强类型的变量赋指给其他变量的时候进行类型检查。弱化参数i, r, p, a, c, z同样适用于X并起相同的作用。 |
|
J |
选项是当强类型与其它类型进行如下的二进制操作时进行检查，下面是J的参数： 使用忽略意味着不会产生告警信息。举个例子，如果Meters是个强类型，那么它只在判断相等和其他关系操作时才会被正确地检查，其它情况则不检查，在这个例子中使用J选项是正确的。 |
|
B |
B选项有两个效果： |
|
b |
仅仅假定每一个Bolean类操作符都将返回一个与Type类型兼容的返回值。与B选项相比，b选项的限制比较宽松。 |
|
l |
库标志，当强类型的值作为参数传递给库函数等情况下，不产生告警。 |
|
f |
与B或b连用，表示抑止对1bit长度的位域是Boolean类型的假定，如果不选该项表示1bit长度的位域被缺省假定为Boolean类型。 |
这些选项字符的顺序对功能没有影响。但是A和J选项的弱化字符必须紧跟在它们之后。B选项和b选项不能同时使用，f选项必须搭配B选项或b选项使用，如果不指定这些选项，-strong的作用就是仅仅声明type为强类型而不作任何检查。下面用一段代码演示-strong选项的用法：
//lint -strong(Ab,Bool) <选项是以注释的形式插入代码中>
typedef int Bool;
Bool gt(int a, b)
{
if(a) return a > b; // OK
else return 0; // Warning
}
例子代码中Bool被声明成强类型，如果没有指定b选项，第一个return语句中的比较操作就会被认为与函数类型不匹配。第二个return语句导致告警是因为0不是各Bool类型，如果添加c选项，例如-strong(Acb,Bool)，这个告警就会被抑制。再看一个例子：
typedef char *STRING;
STRING s;
...
s = malloc(20);
strcpy( s, "abc" );
由于malloc和strcpy是库函数，将malloc的返回值赋给强类型变量s或将强类型变量s传递给strcpy时会产生强类型冲突，不过l选项抑制了这个告警。
强类型也可用于位域，出于强类型检查的目的，先假定位域中最长的一个字段是优势Boolean类型，如果没有优势Boolean或位域中没有哪个字段比其它字段长，这个类型从位域被切开的位置开始成为“散”类型，例如：
//lint -strong( AJXb, Bool )
//lint -strong( AJX, BitField )
typedef int Bool;
typedef unsigned BitField;
struct foo
{
unsigned a:1, b:2;
BitField c:1, d:2, e:3;
} x;
void f()
{
x.a = (Bool) 1; // OK
x.b = (Bool) 0; // strong type violation
x.a = 0; // strong type violation
x.b = 2; // OK
x.c = x.a; // OK
118
x.e = 1; // strong type violation
x.e = x.d; // OK
}
上面例子中，成员a和c是强类型Bool，成员d和e是BitField类型，b不是强类型。为了避免将只有一位的位域假设成Boolean类型，需要在声明Boolean的-strong中使用f选项，上面的例子就应该改成这样：-strong(AJXbf,Bool)。
另一个强类型检查选项是index，index的用法是：
-index( flags, ixtype, sitype [, sitype] ... )
这个选项是对strong选项的补充，它可以和strong选项一起使用。这个选项指定ixtype是一个排除索引类型，它可以和Strongly Indexed类型sitype的数组（或指针）一起使用，ixtype和sitype被假设是使用typedef声明的类型名称。flags可以是c或d，c允许将ixtype和常量作为索引使用，而d允许在不使用ixtype的情况下指定数组的长度（Dimensions）。下面是一个使用index的例子：
//lint -strong( AzJX, Count, Temperature )
//lint -index( d, Count, Temperature )
// Only Count can index a Temperature
typedef float Temperature;
typedef int Count;
Temperature t[100]; // OK because of d flag
Temperature *pt = t; // pointers are also checked
// ... within a function
Count i;
t[0] = t[1]; // Warnings, no c flag
for( i = 0; i < 100; i++ )
t[i] = 0.0; // OK, i is a Count
119
pt[1] = 2.0; // Warning
i = pt - t; // OK, pt-t is a Count
上面的例子中，Temperature是被强索引类型，Count是强索引类型。如果没有使用d选项，数组的长度将被映射成固有的类型：
Temperature t[ (Count) 100 ];
但是，这是个小麻烦，像下面那样将数组长度定义成常量更好一些：
#define MAX_T (Count) 100
Temperature t[MAX_T];
这样做还有一个好处就是同样的MAX_T还可以用在for语句中，用于限制for语句的范围。需要注意的是，指向强被索引类型的指针（例如上面的pt）如果用在[]符号（数组符号）中也会被检查类型。其实，无论何时，只要将一个值加到一个指向强被索引类型的指针时，这个值就会被检查以确认它是一个强索引类型。此外，强被索引指针如果减去一个值，其结果被认为是平常的强索引，所以下面的例子就不会产生告警：
i = pt - t;
3.2 变量值跟踪
3.2.1 变量值初始化跟踪
早期的变量值跟踪技术主要是对变量值的初始化进行跟踪，和变量初始化相关的LINT消息主要是644, 645 ("变量可能没有初始化"), 771, 772 ("不可靠的初始化"), 530 ("未初始化的"), and 1401 - 1403 ("成员 ... 未初始化")。以下面的代码为例：
if( a ) b = 6;
else c = b; // 530 message
a = c; // 645 message
假设b和c在之前都没有初始化，PC-Lint就会报告b没有初始化（在给c赋值的时候）和c可能没有被初始化（在给a赋值的时候）的消息。而while和for循环语句和上面的if语句稍微有所不同，比较下面的代码：
while ( n-- )
{
b = 6;
...
}
c = b; //772 message
假设b在使用之前没有被初始化，这里会报告b可能没有初始化的消息（当给c赋值时）。之所以会有这样的区别，是因为程序设计者可能知道这样的循环体总是会被至少执行一次。相反，前面的if语句，对于程序设计者来说比较难以确定if语句是否总会被执行，因为如果是这样的话，这样的if语句就是多余的，应该被去掉。While语句和if比较相似，看下面的例子：
switch ( k )
{
case 1: b = 2; break;
case 2: b = 3;
case 3: a = 4; break;
default: error();
}
c = b; //645 message
尽管b在两个不同的地方被赋值，但是仍然存在b没有被初始化的可能。因此，当b赋值给c的时候，就会产生可能没有初始化的消息。为了解决这个问题，你可以在switch语句之前给b赋一个默认值。这样PC-Lint就不会产生告警消息，但是我们也失去了让PC-Lint检查后续的代码修改引起的变量初始化问题的机会。更好的方法是修改没有给b赋值的case语句。
如果error()语句代表那些“不可能发生”的事情发生了，那么我们可以让PC-Lint知道这一段其实是不可能执行的，下面的代码表明了这一点：
switch ( k )
{
case 1: b = 2; break;
case 2:
case 3: b = 3; a = 4; break;
default: error();
}
c = b;
注意：这里的-unreachable应该放在error()后面，break的前面。另外一个产生”没有初始化”告警的方式是传递一个指针给free（或者采用相似的方法）。比如：
if( n ) free( p );
...
p->value = 3;
在访问p的时候会产生p可能没有被初始化的消息。对于goto语句，前向的goto可能产生没有初始化消息，而向后的goto 会被忽略掉这种检查。
if ( a ) goto label;
b = 0;
label: c = b;
当在一个大的项目中使用未初始化变量检查时，可能会产生一些错误的报告。这种报告的产生，很大一部分来自于不好的程序设计风格，或者包括下面的结构：
if( x ) initialize y
...
if( x ) use y
当出现这种情况时，可以采用给y赋初始值的方式，或者利用选项-esym(644,y)关掉变量y上面的初始化检查。
3.2.2 变量值跟踪
变量值跟踪技术从赋值语句、初始化和条件语句中收集信息，而函数的参数被默认为在正确的范围内，只有在从函数中可以收集到的信息与此不符的情况下才产生告警。与变量值跟踪相关的消息有：
(1) 访问地址越界消息（消息415，661，796）
(2) 被0除消息（54，414，795）
(3) NULL指针的错误使用（413，613，794）
(4) 非法指针的创建错误（416，662，797）
(5) 冗余的布尔值测试（774）
看下面的例子：
int a[10];
int f()
{
int k;
k = 10;
return a[k]; // Warning 415
}
这个语句会产生警告415（通过 '[' 访问越界的指针），因为PC-Lint保存了赋给k的值，然后在使用k的时候进行了判断。如果我们把上面的例子稍加修改：
int a[10];
int f( int n )
{
int k;
if ( n ) k = 10;
else k = 0;
return a[k]; // Warning 661
}
这样就会产生告警 661 (可能访问越界指针)。使用“可能”是因为不是所有的路径都会把10赋值给k。PC-Lint不仅收集赋值语句和初始化，还从条件语句中收集值的信息。比如下面的例子：
int a[10];
int f( int k, int n )
{
if ( k >= 10 ) a[0] = n;
return a[k]; // Warning 661 -- k could be 10
}
这里仍然产生661告警，因为PC-Lint检测到，在使用k的时候，k的值>=10。另外，对于函数来说，它总是假设K是正确的，程序使用者知道他们要做些什么，所以下面的语句不会产生告警：
int a[10];
int f( int k, int n )
{ return a[k+n]; } // no warning
和检查变量没有初始化一样，还可以检查变量的值是否正确。比如，如果下面例子中的循环一次都没有运行，k可能会超出范围。这时候会产生消息796 (可预见的地址访问越界).
int a[10];
int f(int n, int k)
{
int m = 2;
if( k >= 10 ) m++; // Hmm -- So k could be 10, eh?
while( n-- )
{ m++; k = 0; }
return a[k]; // Info 796 - - k could still be 10
}
下面的例子演示了可能使用NULL指针的问题：
int *f( int *p )
{
if ( p ) printf( "\n" ); // So -- p could be NULL
printf( "%d", *p ); // Warning
return p + 2; // Warning
}
这里会产生两个告警，因为可能使用了NULL指针，很明显，这两个语句应该在if语句的范围内。为了使你的程序更加健壮，你可能需要打开Pointer-parameter-may-be-NULL这个开关（+fpn）。这个选项假设所有传递到函数中的指针都有可能是NULL的。数组边界值在高位被检测，也就是说
int a[10]; ... a[10] = 0;
被检测了，而a[-1]却检测不到。PC-Lint中有两个消息是和指针的越界检查有关的，一个是越界指针的创建，另外一个是越界指针的访问，也就是通过越界指针获取值。在ANSI C([1]3.3.6)中，允许创建指向超过数组末尾一个单元的指针，比如：
int a[10];
f( a + 10 ); // OK
f( a + 11 ); // error
但是上面创建的两个指针，都是不能访问的，比如：
int a[10], *p, *q;
p = a + 10; // OK
*p = 0; // Warning (access error)
p[-1] = 0; // No Warning
q = p + 1; // Warning (creation error)
q[0] = 0; // Warning (access error)
布尔条件检查不象指针检查那么严格，但是它会对恒真的布尔条件产生告警，比如：
if ( n > 0 ) n = 0;
else if ( n <= 0 ) n = -1; // Info 774
上面的代码会产生告警（774），因为第二个条件检查是恒真的，可以忽略。这种冗余代码不会导致问题，但它的产生通常是因为逻辑错误或一种错误可能发生的征兆，需要详细的检查。
3.2.3 使用assert（断言）进行补救
在某些情况下，虽然根据代码我们可以知道确切的值，但是PC-Lint却无法获取所有情况下变量的值的范围，这时候会产生一些错误的告警信息，我们可以使用assert语句增加变量取值范围信息的方法，来抑制这些错误的告警信息的产生。下面举例来说明：
char buf[4];
char *p;
strcpy( buf, "a" );
p = buf + strlen( buf ); // p is 'possibly' (buf+3)
p++; // p is 'possibly' (buf+4)
*p = 'a'; // Warning 661 - possible out-of-bounds reference
PC-Lint无法知道在所有情况下变量的值是多少。在上面的例子中，产生告警的语句其实并不会带来什么危害。我们可以直接使用
*p = 'a'; //lint !e661
来抑制告警。另外，我们还可以使用assert工具来修正这个问题：
#include <assert.h>
...
char buf[4];
char *p;
strcpy( buf, "a" );
p = buf + strlen( buf );
assert( p < buf + 3 ); // p is 'possibly' (buf+2)
p++; // p is 'possibly' (buf+3)
*p = 'a'; // no problem
由于assert在NDEBUG被定义时是一个空操作，所以要保证Lint进行的时候这个宏没有被定义。
为了使assert()和你的编译器自带的assert.h一起产生上面的效果，你需要在编译选项文件中添加一个选项。例如，假设assert 是通过以下的编译器宏定义实现的：
#define assert(p) ((p) ? (void)0 : __A(...))
考虑到__A()会弹出一个消息并且不会返回，所以这个需要添加的选项就是：
-function( exit, __A )
这个选项将exit函数的一些非返回特征传递给__A函数。做为选择结果，编译器可能将assert实现成一个函数，例如：
#define assert(k) _Assert(k,...)
为了让PC-lint知道_Assert是一个assert函数，你需要使用-function( __assert, _Assert )选项或-function( __assert(1), _Assert(1) )选项复制__assert()函数的语义
许多编译器的编译选项文件中已经存在这些选项了，如果没有的话，你可以复制一个assert.h文件到PC-lint目录下（这个目录由于使用了-i选项，文件搜索的顺序优先于编译器的头文件目录）。
3.2.4 函数内变量跟踪
PC-Lint的函数值跟踪功能会跟踪那些将要传递给函数（作为函数参数）变量值，当发生函数调用时，这些值被用来初始化函数参数。这种跟踪功能被用来测定返回值，记录额外的函数调用，当然还可以用来侦测错误。考察下面的例子代码：
t1.cpp:
1 int f(int);
2 int g()
3 { return f(0); }
4 int f( int n )
5 { return 10 / n; }
在这个例子中，f()被调用的时候使用0作为参数，这将导致原本没有问题的10/n语句产生被0除错误，使用命令lin -u t1.cpp可以得到以下输出：
--- Module: t1.cpp
During Specific Walk:
File t1.cpp line 3: f(0)
t1.cpp 5 Warning 414: Possible division by 0 [Reference:File t1.cpp: line 3]
你第一个注意到的事情是短语“During Specific Walk”，紧接着是函数调用发生的位置，函数名称以及参数，再下来就是错误信息。如果错误信息中缺少了错误再现时的错误行和用来标记错误位置的指示信息，这是因为检查到错误的时候代码（被调用函数的代码）已经走过了。如果像下面一样调换一下两个函数的位置：
t2.cpp:
1 int f( int n )
2 { return 10 / n; }
3 int g()
4 { return f(0); }
这种情况下就不会出现被0除的告警，因为此时f(0)在第四行，函数f()的代码已经过了，在这种情况下就需要引入multi-pass选项。如果在刚才的例子中使用lin -u -passes(2) t2.cpp命令，那么输出就变成：
--- Module: t2.cpp
/// Start of Pass 2 ///
--- Module: t2.cpp
During Specific Walk:
File t2.cpp line 4: f(0)
t2.cpp 2 Warning 414: Possible division by 0 [Reference:File t2.cpp: line 4]
使用-passes(2)选项将会检查代码两遍，一些操作系统不支持在命令行中使用-passes(2)，对于这样的系统，可以使用-passes=2 或 -passes[2]代替。通过冗长的信息可以看出来，以pass 2开始表示第一次检查没有产生告警信息。这一次得到的错误信息和前一次不同，在某种情况下我们可以推断出指定函数调用的返回值，至少可以得到一些返回值的属性。以下面的模块为例：
t3.cpp:
1 int f( int n )
2 { return n - 1; }
3 int g( int n )
4 { return n / f(1); }
使用命令 lin -u -passes(2) t3.cpp，可以得到以下输出信息：
--- Module: t3.cpp
/// Start of Pass 2 ///
--- Module: t3.cpp
{ return n / f(1); }
t3.cpp 4 Warning 414: Possible division by 0 [Reference:File t3.cpp: lines 2, 4]
第一遍检查我们知道调用函数f()传递的参数是1，第二遍检查先处理了函数f()，我们推断出这个参数将导致返回结果是0，当第二遍检查开始处理函数g()的时候，产生了被0除错误。应该注意到这个信息并不是在短语“During Specific Walk”之前出现的，这是因为错误是在对函数g()进行正常的处理过程中检测到的，此时并没有使用为函数g()的参数指定的值。指定的函数调用能够产生附加的函数调用，如果我们pass足够多的检测次数，这个过程可能会重复发生，参考下面的代码：
t4.cpp:
1 int f(int);
2 int g( int n )
3 { return f(2); }
4 int f( int n )
5 { return n / f(n - 1); }
第五行的分母f(n-1)并不会引起怀疑，直到我们意识到f(2)调用将导致f(1)调用，最终会调用f(0)，迫使最终的返回值是0。使用下面的命令行：
lin -u -passes(3) t4.cpp，
输出结果如下：
--- Module: t4.cpp
{ return f(2); }
t4.cpp 3 Info 715: Symbol 'n' (line 2) not referenced
/// Start of Pass 2 ///
--- Module: t4.cpp
/// Start of Pass 3 ///
--- Module: t4.cpp
During Specific Walk:
File t4.cpp line 3: f(2)
File t4.cpp line 5: f(1)
t4.cpp 5 Warning 414: Possible division by 0 [Reference:File t4.cpp: lines 3, 5]
到这里已经处理了三遍才检测到可能的被0除错误，想了解为什么需要处理三遍可以看看这个选项-specific_wlimit(n)。需要注意的是，指定的调用序列，f(2)，f(2)，是作为告警信息的序言出现的。
3.3 赋值顺序检查
当一个表达式的值依赖于赋值的顺序的时候，会产生告警564。这是C/C++语言中非常普遍的一个问题，但是很少有编译器会分析这种情况。比如
n++ + n
这个语句是有歧义的，当左边的+操作先执行的话，它的值会比右边的先执行的值大一，更普遍的例子是这样的：
a[i] = i++;
f( i++, n + i );
第一个例子，看起来好像自加操作应该在数组索引计算以后执行，但是如果右边的赋值操作是在左边赋值操作之前执行的话，那么自加一操作就会在数组索引计算之前执行。虽然，赋值操作看起来应该指明一种操作顺序，但实际上是没有的。第二个例子是有歧义的，是因为函数的参数值的计算顺序也是没有保证的。能保证赋值顺序的操作符是布尔与（&&）或（||）和条件赋值（? :）以及逗号(,)，因此：
if( (n = f()) && n > 10 ) ...
这条语句是正确的，而：
if( (n = f()) & n > 10 ) ...
将产生一条告警。
3.4 弱定义检查
这里的弱定义包含是以下内容：宏定义、typedef名字、声明、结构、联合和枚举类型。因为这些东西可能在模块中被过多定义且不被使用，PC-Lint有很多消息用来检查这些问题。PC-Lint的消息749-769 和1749-1769都是保留用来作为弱定义提示的。
(1) 当一个文件#include的头文件中没有任何引用被该文件使用，PC-Lint会发出766告警。
(2) 为了避免一个头文件变得过于大而臃肿，防止其中存在冗余的声明，当一个头文件中的对象声明没有被外部模块引用到时，PC-Lint会发出759告警。
(3) 当变量或者函数只在模块内部使用的时候，PC-Lint会产生765告警，来提示该变量或者函数应该被声明为static。
如果你想用PC-Lint检查以前没有检查过的代码，你可能更想将这些告警信息关闭，当然，如果你只想查看头文件的异常，可以试试这个命令：
lint -w1 +e749 +e?75? +e?76? ...
3.5 格式检查
PC-Lint会检查printf和scanf(及其家族)中的格式冲突，例如：
printf( "%+c", ... )
将产生566告警，因为加号只在数字转换时有用，有超过一百个这样的组合会产生告警，编译器通常不标记这些矛盾，其他的告警还有对坏的格式的抱怨，它们是557和567。我们遵循ANSI C建立的规则，可能更重要的是我们还对大小不正确的格式进行标记（包括告警558, 559, 560 和 561）。比如 %d 格式，允许使用int和unsigned int，但是不支持double和long（如果long比int长），同样，scanf需要参数指向的对象大小正确。如果只是参数的类型（不是大小）与格式不一致，那将产生626和627告警。-printf 和 -scanf选项允许用户指定与printf或scanf函数族类似的函数，-printf_code 和 -scanf_code也可以被用来描述非标准的 % 码。
3.6 缩进检查
根据代码中的缩进问题，PC-Lint也会产生相应的告警，因为缩进的问题有很大一部分是由于代码结构不良或者大括号的遗漏造成的。比如下面的例子：
if( ... )
if( ... )
statement
else statement
很明显这里的else是和第一个if语句对应的，而在这里编译器则把它和第二个if对应起来。PC-Lint会对这种情况产生告警。和这样的缩进检查相关的告警主要有三个725(no positive indentation)、525(negatively indented from)、539（Did not expect positive indentation from Location）要进行缩进检查，我们首先要设置文件中的tab键所对应的空格数，默认的是占用8个空格，这个参数可以用-t#选项进行修改。比如-t4表示tab键占用4个空格长度。另外，缩进检查还和代码的编码格式策略相关，需要进行必要的调整。
3.7 const变量检查
对于const变量的检查，PC-Lint是完全支持的。使用const变量，对于提高代码的质量非常有好处，看一下下面的例子：
char *strcpy( char *, const char * );
const char c = 'a';
const char *p = &c;
void main()
{
char buf[100];
c = 'b';
*p = 'c';
strcpy( p, buf );
...
这里的c和*P指向的内容都是静态变量，不可修改。上面的代码明显违反了这个规定，会产生Error(11)，另外，把P作为第一个参数传入strcpy中，会产生告警605（Increase in pointer capability），而把buf作为第二个参数传入strcpy函数中，会产生告警603（Symbol 'Symbol' (Location) not initialized），因为buf没有初始化，而作为静态变量的第二个参数，是不能在strcpy函数中再被初始化的。
3.8 volatile变量检查
对于volatile变量的检查，在PC-Lint中有这样的规定，如果一个表达式中同时使用了两次相同的volatile变量，那么就会给出564告警，因为这时候会产生赋值顺序的问题。
volatile char *p;
volatile char f();
n = (f() << 8) | f();
n = (*p << 8) | *p;
4.1 安装与配置
PC-lint软件性价比高，易于学习，容易推广和固化到软件开发测试流程中去，所以在全世界得到了广泛的应用。PC-lint使用方法很简单，可以用命令行方式进行，例如lint-nt –u std.lnt test1.c test2.c test3.c 也可以使用MAKEFILE的方式。此外，它还可以集成到很多开发环境或常用的代码编辑软件中，比如集成到Source Insight/SLICKEDIT/MS VC6.0/KEIL C..等。PC-Lint还支持Scott Meyes的名著（Effective C++/More Effective C++）中说描述的各种提高效率和防止错误的方法。
PC-lint的安装非常简单，以PC-lint 8.0为例，运行安装程序将其释放到指定的安装目录即可，比如c:\pclint8。然后需要运行PC-lint的配置工具config.exe生成选项和检查配置文件，以刚才的安装路径为例，config.exe应该位于：C:\pclint8\config.exe。配置文件是代码检查的依据，PC-lint自带了一个标准配置文件std.lnt，但是这个文件没有目录包含信息（头文件目录），通常对代码检查的时候都需要指定一些特殊的包含目录，所以要在标准配置的基础上生成针对某个项目代码检查的定制配置。下面就以Microsoft Visual C++ 6的开发环境为例，介绍一下定制配置的过程。
运行C:\pclint8\config.exe后出现一个欢迎界面，提示版权信息，如图4.1所示：
图4.1 配置欢迎窗口
点击“下一步”按钮出现pc-lint.exe命令行使用说明窗口（图4.2所示）：
图4.2 pc-lint.exe命令行使用说明窗口
点击“下一步”按钮继续，接着是选择创建或修改已有配置文件STD.LNT的选项：
图4.3 选择如何使用配置文件STD.LNT
因为我们是第一次配置，所以选择上面一个选项“Create a new STD.LNT”，这样做不会修改已有配置文件STD.LNT的内容，而是创建一个新的STD_x.LNT文件，文件名中的x是从“a”到“z”26个英文字符中的任意一个，一般是按顺序排列，从“a”开始。STD_x.LNT文件的内容被初始化为STD.LNT内容的拷贝。如图4.3所示，使用默认的PC-Lint路径，然后点击“下一步”按钮选择编译器：
图4.4 选择编译器
接下来是选择编译器，在下拉框中选择自己使用的编译器。这里我们选择“Microsoft Visual C++ 6.x (co-msc60.lnt)”。如果没有自己使用的编译器，可选择通用编译器“Generic Compilers”。这个选项会体现在co-xxx.lnt文件中，并存放在前面我们选择的配置路径（C:\PCLint8）下，在后面配置选项我们所选择的***.LNT均会被存放到这个路径下。点击“下一步”按钮选择内存模式：
图4.5 选择内存模式
可以根据自己程序区和数据区的实际大小选择一个恰当的内存模型，内存模型的选项会体现在STD.LNT文件或新创建的STD_x.LNT中。因为我们的开发环境是32位的Windows，所以选择“32-bit Flat Model”，然后点击“下一步”按钮选择所要的支持库的配置信息：
图4.6 选择软件库的配置信息
PC-Lint对现在常用的一些软件库都提供了定制的配置信息，选择这些定制信息有助于开发人员将错误或信息的注意力集中在自己的代码中，选择的支持库配置将被引入到STD.LNT文件或新创建的STD_x.LNT文件中。选择常用的ATL、MFC、STL等配置，然后点击“下一步”按钮：
图4.7 选择软件名人的编程建议
这是一个比较有意思的选项，就是让你选择是否支持为使用C/C++编程提出过重要建议的作者的一些关于编程方面的个人意见。如果选择某作者的建议，那么他提出的编程建议方面的选项将被打开，作者建议的配置名为AU-xxx.LNT，建议全部选择，然后点击“下一步”按钮：
图4.8 选择是否现在设置包含文件目录
接下来是选择用何种方式设置包含文件目录，如果选择使用-i方式协助设置包含文件选项，下一步就会要求输入一个或多个包含路径。也可以跳过这一步，以后手工修改配置文件，-i选项体现在STD.LNT文件或新创建的STD_x.LNT文件中，每个目录前以-i引导，目录间以空格分隔，如果目录名中有长文件名或包含空格，使用时要加上双引号，如-i“E:\Program Files\Microsoft Visual C++\VC98\Indlue”。这里我们选择用-i方式协助我们来设置，然后点击“下一步”按钮：
图4.9 选择是否现在设置包含文件目录
这一步就是在下面的文本框里可手工输入文件包含路径，用分号“;”或用ctrl+Enter换行来分割多个包含路径，或者可以点中Brows，在目录树中直接选择。填完后点击“下一步”按钮：
图4.10 提示std_x.lnt已经被创建
因为第三步选择了“Create a new STD.LNT”选项，所以出现以下对话框，表示std_x.lnt，std.lnt在配置路径下已被创建，这里的std_a.lnt实际上包含了std.lnt的信息，除此之外还有我们选择的包含路径和库配置信息。单击“确定”按钮继续：
图4.11 提示是否为其它编译环境创建配置文件
选择“确定”后，会接着提示是否为其它编译环境创建配置文件，如果选择“是”将从第四步开始创建一个新的配置文件。这里我们选择“否”：
图4.12 是否替换std.lnt文件
接下来会提示是否使用现在生成的std_x.lnt文件取代std.lnt文件。如果选择“是”将会用std_x.lnt文件的内容覆盖std.lnt文件的内容，使得当前创建的配置选项成为以后创建新的配置文件时的缺省配置。通常我们选择“否”继续下一步：
图4.13 生成全局代码检查选项文件OPTIONS.LNT
接下来将会准备产生一个控制全局编译信息显示情况的选项文件OPTIONS.LNT，该文件的产生方式有两种，一种是安装程序对几个核心选项逐一解释并提问你是否取消该选项，如果你选择取消，则会体现在OPTIONS.LNT文件中，具体体现方式是在该类信息编码前加-e，后面有一系列逐一选择核心选项的过程。如果选择第二种选择方式，安装文件会先生成一个空的OPTIONS.LNT文件，等你以后在实际应用时加入必要的选项。这里选择“No”选项，即不取消这些选项，然后单击“下一步”：
图4.14 选择所支持的集成开发环境
接着选择所支持的集成开发环境选项，可选多个或一个也不选，PC-Lint提供了集成在多种开发环境中工作的功能，例如可集成在VC、BC、Source Insight中。这里我们选择Microsift Visual C++ 6.0，这样env-v6.lnt就会被拷贝到配置路径中。然后单击“下一步”：
图4.15 选择LIN.BAT文件的使用方式
安装程序会生成一个LIN.BAT文件，该文件是运行PC-Lint的批处理文件，为了使该文件能在任何路径下运行，安装程序提供了两种方法供你选择。第一种方法是让你选择把LIN.BAT拷贝到任何一个PATH目录下。第二种方法是生成一个LSET.BAT文件，在每次使用PC-LINT前先运行它来设置路径，或者把LSET.BAT文件的内容拷贝到AUTOEXEC.BAT文件中。建议选择第一种方法，指定的目录为当前PC-Lint的安装目录。我们选择第一种方式：“copy LIN.BAT to one of my PATH directory”，然后单击“下一步”输入PATH目录：
图4.16 指定PATH目录
输入安装目录C:\PCLint8作为PATH目录，然后单击“下一步”按钮进入最后的确认窗口：
图4.17 确认完成配置
到此就完成了PC-Lint的安装配置工作，单击“完成”按钮就可以使用PC-Lint了。以上配置过程中在配置路径下产生的多个*.lnt文件，除了std.lnt、std_x.lnt和option.lnt为配置向导所生成，其它co-xxx.lnt、lib-xxx.lnt、env-xxx.lnt均是从原始安装目录中拷贝出来的，在这个目录下还有其它PCLint所支持的编译器、库及集成开发环境的lnt配置文件，所有的lnt文件均为文本文件。
上面的配置方法适合于刚开始接触PC-lint时使用，对于熟练的使用者可以直接编辑、编写各*.lnt配置文件安成上面的配置工作，或者定制出更适合自己使用的配置环境。
4.2 PC-Lint与常用开发工具的集成
PC-Lint的使用方法很简单，可以用命令行方式进行，也可以集成到开发环境中，下面就分别介绍这些用法
4.2.1 使用命令行方式
命令行的使用方式是PC-lint最基本的使用方式，也是其他各种集成使用方式的基础，通过命令行可以完成PC-lint的全部代码分析工作。PC-lint的命令行有下列形式：
Lint-nt option file1 [file1 file3 …]
其中的Lint-nt是PC-lint在Windows NT/2000/XP平台上的可执行程序Lint-nt.exe，它完成PC-lint的基本功能；option代表PC-lint可接受的各种选项，这是PC-lint最为复杂的部分，它的选项有300多种，可以分为：错误信息禁止选项、变量类型大小选项、冗余信息选项、标志选项、输出格式选项和其他选项等几类，这些选项在本文的第三部分已经介绍过了；file为待检查的源文件。
另外值得注意的一点是，在命令行中可以加入前面提到的*.lnt配置文件名，并可以把它看作是命令行的扩展，其中配置的各种选项和文件列表，就和写在命令行中具有一样的效果。
4.2.2 PC-Lint与Visual C++集成开发环境（IDE）集成
在所有集成开发环境中，PC-Lint 8.0对VC++6和VC++7.0的支持是最完善的，甚至支持直接从VC的工程文件（VC6是*.dsp，VC7是*.vcproj）导出对应工程的.Lnt文件，此文件包含了工程设置中的预编译宏，头文件包含路径，源文件名，无需人工编写工程的.Lnt文件。
PC-Lint与VC集成的方式就是在VC的集成开发环境中添加几个定制的命令，添加定制命令的方法是选择“Tools”的“Customize...”命令，在弹出的Customize窗口中选择“Tools”标签，在定制工具命令的标签页中添加定制命令。首先要为VC的集成开发环境添加一个导出当前工程的.Lnt配置文件的功能，导出.Lnt文件的命令行是：
lint-nt.exe +linebuf $(TargetName).dsp>$(TargetName).lnt
参数+linebuf表示加倍行缓冲的大小，最初是600 bytes，行缓冲用于存放当前行和你读到的最长行的信息。$(TargetName)是VC集成开发环境的环境变量，表示当前激活的Project名字，注意要选中“Use Output Window”选项，这样PC-Lint就会将信息输出到Output窗口中。填写效果如图4.18所示：
图4.18 添加导出项目.Lnt文件的定制命令
接着添加一个检查当前文件的定制命令，检查文件的命令行为：
lint-nt.exe -i"C:\PCLint8" -u std_g.lnt env-vc6.lnt "$(FileName)$(FileExt)"
第一个参数-i"C:\PCLint8"为PC-Lint搜索*.lnt文件的目录，这里就是我们的配置路径。std_g.lnt是为VC编译环境定制的配置文件，$(FileName)和$(FileExt)是VC集成开发环境的环境变量，"$(FileName)$(FileExt)"表示当前文件的文件名。和导出.Lnt命令一样，这个命令也要使用VC集成环境的Output窗口输出检查信息，所以要选中“Use Output Window”选项，如图4.19所示：
图4.19 添加检查当前文件文件的定制命令
最后要添加一个检查整个工程的定制命令，检查整个工程的命令行是：
lint-nt.exe +ffn -i"C:\PCLint8" std_g.lnt env-vc6.lnt $(TargetName).lnt>$(TargetName).chk
这个命令的结果就是将整个工程的检查结果输出到与工程同名的.chk文件中。参数中+ffn表示Full File Names，可被用于控制是否使用的完整路径名称表示。
下面就以一个简单的例子介绍一下如何在VC集成开发环境中使用PC-Lint。首先新建一个“Win32 Console Application”类型的简单工程（输出“Hello World”），然后将本文第二章引用的例子代码添加到工程的代码中，最后将这个工程代码所倚赖的包含目录手工添加到配置文件中，因为代码检查要搜索stdafx.h这个预编译文件，所以本例要手工添加工程代码所在的目录。本文的例子生成的配置文件是std_g.lnt，用文本文件打开std_g.lnt,在文件中添加一行：
-iC:\unzipped\test
“C:\unzipped\test”就是例子工程所在的目录（stdafx.h就在这个目录）。如果你的工程比较庞大，有很多头文件包含目录，就需要将这些目录一一添加到配置文件。在确保代码输入没有错误之后（有错误页没关系，PC-Lint会检查出错误），就可以开始代码检查了。例子工程，打开要检查的代码文件，本例是test.cpp，然后选择“Tools”菜单下的“PC_LINT 8.0 Check Current File”命令，Output窗口输出对本文件的检查结果，如图4.20所示：
图4.20 检查结果
4.2.3 PC-Lint与source insight集成
PC-Lint与source insight的集成也是通过添加定制命令实现的，从“Options”菜单中选择“Custom Commands”命令项。点击“Add…”按钮，如图4.21所示，在弹出的“Custom Commands”窗口中完成以下输入：
在Name栏中输入“PC-lint Check Current File”，原则上这个名称可以随便起，只要你能搞清楚它的含义就可以了；
在Run栏中输入“C:\PcLint\lint-nt -u -iC:\PcLint\Lint std_f env-si %f”其中C:\PcLint是你PC-LINT的安装目录，std_f表示为Source Insight定制的配置文件std_f.lnt；
在Output栏中选择“Iconic Window”、“Capture Output”选项；
在Control栏中选择“Save Files First”；
在Source Links in Output栏中选择“Parse Links in Output”、“File，then Line”；
在Pattern栏中输入“^\([^ ]*\) \([0-9]+\)”；
图4.21 在Source Insight中添加定制命令
命令添加完成后就可以点击“Run”按钮就可以对当前文件执行PC-Lint检查。为了方便使用，还可以点击“Menu...”按钮将这个定制命令添加到Source Insight的菜单中。
4.2.4 PC-Lint与UltraEdit集成
在UltraEdit中集成PC-Lint的方法和Source Insight类似，也是添加一个定制命令菜单，具体实现方法是先单击UltraEdit的“高级”菜单中的“工具配置”命令，如图4.22所示，在打开的配置窗口中依次输入以下内容：
在“菜单项目名”栏输入“PC-lint Check Current File”；
在“命令行”栏输入以下命令：C:\PCLint\lint-nt –u -iC:\PCLint std env-si %f 其中，C:\PCLint是PC-Lint的安装目录，使用std.lnt中的配置，由于UltraEdit和Source Insightde 的检查环境类似，所以借用env-si中的环境配置；
在“工作目录”栏输入以下路径：E:\code，这是代码所在目录；
选中“先保存所有文件”选项；
在“命令输出”栏中，选中“输出到列表”和“捕捉输出”两个选项；
点“插入”将命令行插入UltraEdit的菜单中；
图4.22 在UltraEdit中添加定制命令
此时在UltraEdit的“高级”菜单中会增加一个“PC-lint Check Current File”菜单，点击该菜单即可对当前文件执行PC-lint检查。
软件除错是软件项目开发成本和延误的主要因素，PC-lint能够帮你在程序动态测试之前发现编码错误，降低软件消除错误的成本。使用PC-Lint在代码走读和单元测试之前进行检查，可以提前发现程序隐藏错误，提高代码质量，节省测试时间。另外，使用PC-lint的编码规则检查，可以有效地规范软件人员的编码行为。如果能够在软件开发过程中有效地使用PC-lint代码检查工具，将大大地提高代码质量，降低软件成本。
[1] Gimpel Software. Reference Manual for PC-lint/FlexeLint. July,2001
[2] PC-Lint选项详解
Msg.txt ：解释告警的内容。
options.lnt ：反映全局编译信息显示情况的选项文件，通常需要添加自定选项以使代码检查更为严格。
env-xx.lnt ：讲述如何将PC-lint与对应的编辑环境结合起来，xx是si表示是为Source Insight配置的检查环境，xx是vc6则表示是为Visual C++ 6.0准备的检查环境。
co-xxx.lnt ：选定的编译器与库选项。
std.lnt ：标准配置文件，包含内存模型等全局性东西。
lib-xxx.lnt ：库类型的列表，包括标准C/C++库，MFC库，OWL库等等。
au-xxx.LNT ：C++编程提出过重要建议的作者，选择某作者后，他提出的编程建议方面的选项将被打开。
命令格式 说明 代码中的举例
-e# 隐藏某类错误
-e(#) 隐藏下一表达式中的某类错误
printf(“it’s all”);
!e# 隐藏本行中的错误 printf(“it’s all”);
-esym(#, Symbol) 隐藏有关某符号的错误
printf(“it’s all”);
-elib(#) 隐藏头文件中的某类错误
#include “r01.h”
-efunc(#, <func>) 隐藏某个函数中的特定错误
unsigned int mchRelAll(mchHoData
*pHoData)
{
printf(“it’s all”);
}
错误编码 错误说明 举例
40 变量未声明
506 固定的Boolean值 char c=3;
if(c<300){}
525 缩排格式错误
527 无法执行到的语句 if(a > B)
return TRUE;
else
return FALSE;
return FALSE;
529 变量未引用 检查变量未引用的原因
530 使用未初始化的变量
534 忽略函数返回值
539 缩排格式错误
545 对数组变量使用& char arr[100], *p;
p=&arr;
603 指针未初始化 void print_str(const char *p);
…
char *sz;
print_str(sz);
605 指针能力增强 void write_str(char *lpsz);
…
write_str(“string”);
613 可能使用了空指针
616 在switch语句中未使用break;
650 比较数值时，常量的范围超过了 if( ch == 0xFF ) ...
变量范围
713 把有符号型数值赋给了无符号型
数值
715 变量未引用
725 Indentation错误
734 在赋值时发生变量越界 int a, b, c;
…
c=a*b;
737 无符号型变/常量和有变量型
变/常量存在于同一个表达式中。
744 在switch语句中没有default
752 本地声明的函数未被使用
762 函数重复声明
774 Boolean表达式始终返回真/假 char c;
if(c < 300)
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=971457
1. PC-Lint 是什么?
如果你真的不知道它是什么? 那么请私下询问 Google, 但千万不要声张:-).
>
简单而言, PC-Lint 是 Gimpel Software 公司出品的一个很牛<注1>的软件, 你可以叫它吹毛求疵器, 因为它能够做比编译器严格得多的(包括但不限于)语法检查.
事实上这个工具有两个版本: 一个叫 PC-Lint, 是针对 PC 机的 (主要是对付 Windows, MS-DOS, OS/2 等系统), 以可执行文件形式发布; 另一个叫 FlexeLint, 是针对其它系统的 (比如 Linux), 采用源码方式发布.
由于很少见到 FlexeLint, 本文仅就 PC-Lint 的使用进行介绍. 目前在官方网上出现的最新版本是 9.0, 但同样不易获得, 所以本文只介绍 PC-Lint8.0. 我们将采用变通的方法实现对 Linux 系统下的代码检查.
2. 使用环境
正如前面所说, PC-Lint 本来只当游弋于 Windows, OS/2 之上, 但由于 C 的标准化做得比较好, 所以稍作变通, PC-Lint 是完全有能力对付那些针对 Linux 系统的代码的.
>
除了操作系统环境, 要想使用得顺手, 还应该把 PC-Lint 和编译/编辑环境结合起来. 现在 PC-Lint 已经能很好地和大部分主流编译/编辑器整合, 使用起来非常方便.
下文将就这两个方面进行讨论.
2.1. 配合 Linux 的使用
在 Linux 系统下, 通常使用 GCC 作为 C 代码的编译器. 为了使 PC-Lint 能有效地检查针对 Linux 的代码, 应该为它选定正确的头 (.h) 文件. 通常这些文件都放在 /usr/include 和 /usr/<x.y.z><注2>/include 目录下.
>
由于 PC-Lint 不能在 Linux 系统上运行, 所以要把上面两个目录映射 (作磁盘映射) 到 Windows 系统, 这样目录就变成了 Z<注3>:\usr\include 和 Z:\usr\<x.y.z>\include. 也可以把 Linux 的头文件直接 COPY 到 Windows 系统中, 这时系统会提示文件重名<注4>, 但这些文件一般用不到, 直接覆盖就行.
为了让 PC-Lint 能认出这两个目录, 要在 std.lnt 文件中增加
-iZ:\usr\include
-iZ:\usr\3.4.3\include
两行.
>
另外由于 PC-Lint 是针对 Windows 设计的, 会抱怨 Linux 某些头文件不正确. 由于我们不提倡自己修改标准文件, 因此干脆让 PC-Lint 暂时失声好了. 这可以通过在 options.lnt 文件增加下面几行实现:
-e716 // allow use while (1)
// bug in syslog.h, it define __need_va_list_ macro
-efile(537,stdarg.h)
-emacro(530,va_start) // do not init first parameter
修改 options.lnt 文件, 使用 gnu 检查规则, 即应该有如下一行:
c:\pclint\lnt\co-gnu3.lnt
假设 PC-Lint 安装在 C:\pclint 目录下.
>
配置好这些, 在 Windows 上检查 Linux 代码就应该比较顺手了.
2.2. 配合 SourceInsight 的使用
在 SourceInsight 中可以新建一个命令. 通过 Custom Commands 窗口, 在其中的 Command 中填入命令名 (比如是 lint), 再在 Run 中 填入
C:\pclint\LINT-NT.EXE -u -ic:\pclint\lnt std.lnt env-si %f
再在 Pattern 框里填写
^\(.*\.[a-zA-Z]+\)\w\([0-9]+\).*
然后点击 Add 按钮即可.
>
此后要对 C 文件进行检查时, 直接执行该命令即可.
3. 配置
上面的配置都是一成不变的, 配置好之后, 基本上都不需要改动了. 但对于不同的项目, 还有一些针对项目本身的特殊配置. 在这一小节, 将对针对特定项目的配置进行说明.
首先, 每个项目都有各自的头文件, 因此需要在 std.lnt 指定项目的头文件目录. 格式如下:
-i<头文件目录>
例如:
-iZ:\sw-new\src\license
>
另外, 如果项目有些目录是第三方提供的, 或者我们不关注其中的警告, 则可以把这些目录指定为库目录. 格式如下:
+libdir(<库目录1>,<库目录2>,...)
例如:
+libdir(z:\usr\include,z:\usr\3.4.3\include,z:\mysql\include)
>
对于以前没检查过的项目, 第一次使用 PC-Lint 检查时, 可能会出现很多警告和错误. 为了不至于使有用的错误掩埋于警告之中, 可以在 options.lnt 中配置全局的检查等级, 使其只显示严重的错误. 方法为:
-w<等级数>
其中等级数越大, 输入的警告错误就越多. 建议逐渐加大此数, 分步消除错误和警告. 比如先从
-w1
开始.
>
还可以使用
-e<错误号>
暂时屏蔽对某个错误的检查.
4. 避免无病呻吟
也会有这样的情况: 对某些代码, 你确认----想想你的论据是否充分, 别急于下此结论哦:-)----没有问题, 但 PC-Lint 却在每次检查时都抱怨, 这时可以通过在代码作特殊注释让 PC-Lint 跳过某些检查.
>
PC-Lint 提供了大量的特殊注释, 可以把这些注释加到代码中, 对代码的每个段落、每一行甚至每个表达式进
行精细的检查控制.
下面列举出一些常用的选项, 更多选项可参数 PC-Lint 的使用手册. 注意这些选项都要放到 C 代码的注释中, 且格式为 /*lint <xxxx> */, 其中 lint 必须紧接在 /* 后面出现, <xxxx> 表示选项, 选项后留一个空格, 然后才是 */.
1). -e(#[,#]...) 仅对下一个表达式有效,
a = /*lint -e(413) */ *(char *)0;
与
a = /*lint -save -e413 */ *(char *)0
/*lint -restore */;
是等价的.
>
2). --e(#[,#]...) 对其所在的整个表达式有效,
a = /*lint --e(413) */ *(int *)0 + *(char *)0;
将阻止两个 413 信息的输出, 而使用 -e(413) 则只阻止第一个 413 输出.
3). -e{#[,#]...} 对下一个语句或者声明有效. 这种用法的影响范围很灵活: 当其在函数之前时, 对整个函数有效; 在某个赋值语句前, 对该个赋值语句有效; 在 if 或 while 等语句前对这整个语句段有效.
4). --e{#[,#]...} 对于其所处的 {} 号内的整个代码体有效, 这包括函数体, 类, 结构等等. 如果不处于任何 {} 号内, 则对整个文件有效 (当然, 是指从 --e{} 出现的地方至文件结束).
5). !e# 仅对其所在行有效.
>
6). -esym(#,sym[,sym]) 对指定的符号屏蔽警告.
5. 常见错误处理
下面列举一些常见的错误, 及处理方法, 供参考:
525 提示错误缩进, 原因是代码中空格和 TAB 键混合使用了, PC-Lint 认为代码的缩进与代码逻辑不符合. 把代码统一改成使用空格即可<注5>.
715 符号未被引用, 原因是在函数中的某个调用参数或者局部变量没被使用. 对局部变量可以直接去掉, 对于参数则把其放到if 语句中即可.
>
740 提示不寻常的类型转换, 通常发生在指针类型转换时, 转换前后指针所指类型空间大小不一致时. 可通过在转换前加
/*lint -e(740) */
的方式屏蔽此警告.
818 函数的指针参数在函数内部没被修改, 提示参数定义为常量指针. 按照提示在指针参数前加上 const 修饰符就可以了. 但是似乎 PC-Lint 在处理这个问题的时候有 BUG, 有时即使加了 const 修饰符还是会继续提示此警告, 此时就应该在对这个函数这个指针参数屏蔽 818 警告, 方法为在函数开始前添加
/*lint -esym(818, pointer) */
在函数结束后添加
/*lint +esym(818, pointer) */
827 不可到达的代码, 原因是在 while (1)/for (;;) 后还有代码, 但这些代码永远无法执行到. 解决方法是在不能执行到的代码行前加上
/*lint -unreachable */
<1> 并非因为是在牛年出品, 而是因为它确实本来就很牛.
<2> 这里是指当前使用的 GCC 版本, 比如 3.4.3.
<3> 假设映射到 Z 盘.
<4> 原因是 Linux 文件名区分大小写, 而 Windows 不区分.
<5> 这种工作可以由 indent 代劳, 相信它, 它能做得很好.
