到底需不需要编译器之外的独立的静态代码检查工具呢？这个问题’仁者见仁，智者见智’。但是有一个结论我想大家都会认可，那就是越是在开发周期早期发现的Bug，修复它所付出的代价就越小。而像lint这样的静态代码检查程序恰恰是让Bug在早期阶段’显露原型’的绝佳工具，而追求’lint-clean’[注1]境界的代码也向来是专家级程序员的嗜好。别忘了在’C专家编程’一书中曾经提到Sun OS的内核一直是保持’lint-clean’状态的，这就是榜样！还等什么？赶快学呀！^_^

有人抱怨’不敢用lint工具, 太多的Warnings把快屏幕都淹没了!’，不过高手一般不这么想，他会细心琢磨这些Warnings背后的’暗示’，并和lint工具沟通，利用lint工具提供的交互方法屏蔽掉一些经过分析认为不能成为错误的Warnings。久而久之，高手本身就成了一个lint程序，就能够很快的用肉眼发现代码中的问题，并指出问题所在，如何解决！他还能告知如何嵌入一些Annotations从而避免让lint程序产生不必要的Warnings，这时这位高手对语言和程序的理解就又提高了一个档次了。其实使用ling工具不仅仅是为了提早发现程序中的Bug，其使用过程有助于你加深对程序的认识和理解。的确事实就是这样。

Splint就是一款强大而且应用广泛的开源lint工具。它的强大的代码检查能力固然让人称道，但是让我更欣赏的却是它提供的’Annotations’机制。Splint可以让程序员在自己的代码中嵌入相应的Anotations，这些Anotations作为Splint分析代码时的输入以帮助Splint产生对程序员更有用的信息。下面是一些Splint的使用入门，更多详细信息请查看’Splint manual‘。

1、最简单的Splint使用方法
>> splint *.c

2、Splint输出Warnings的基本格式
<file>:<line>[,<column>]: message
     [hint]
      <file>:<line>,<column>: extra location information, if appropriate
我们可以使用’+/-<flags>’来自定义其输出格式，如’splint -showcol *c’，则Splint不会在输出信息中显示’列’信息。

3、使用flags控制splint的检查范围和输出格式
‘+<flag>’ — 表明某个flag处于打开状态，如’+unixlib’；
‘-<flag>’ — 表明某个flag处于关闭状态，如’-weak’；

4、使用.splintrc环境文件
如果不想每次使用splint的时候都手工输入一堆’+/-<flags>’，那么你可以把这些’+/-<flags>’预先写到.splintrc文件中，当splint执行的时候它会自动加上这些flags的。默认的flags设置在’~/splintrc’文件中，但是如果一旦splint的当前工作路径下也有.splintrc文件，那么这个.splintrc文件中的flag设置会覆盖’~/splintrc’中的flags设置，但是命令行中的flags设置是具备最高优先级的，它会覆盖前面提到的任何一个文件中的flags设置。

5、使用Annotations
对于’Annotations’的作用，Java程序员并不陌生，但是C程序员则对这个不是那么了解。C代码中的Annotations用来指导Splint生成恰当的代码检查报告。下面这个例子对比使用和不使用Annotations，Splint的输出的差别：
/* testlint.c */
void foo1() {
        /*@unused@*/int *p = NULL;
}

void foo2() {
        int *p = NULL;
}

splint testlint.c
Splint 3.1.1 — 28 Apr 2003

testlint.c: (in function foo2)
testlint.c:6:7: Variable p declared but not used
  A variable is declared but never used. Use /*@unused@*/ in front of
  declaration to suppress message. (Use -varuse to inhibit warning)

Finished checking — 1 code warning

可以看出没使用Annotation的函数foo2被给出Warning了。Splint的Annotations繁多，我们在平时做lint时可以多多接触。

‘早用lint，勤用lint’，这是C专家给我们的建议。’lint-clean’也许离你并不遥远。

[注1]
‘lint-clean’ — 程序能够顺利通过lint程序的检查。

在最近的项目中，我们涉及到了“内存对齐”技术。对于大部分程序员来说，“内存对齐”对他们来说都应该是“透明的”。“内存对齐”应该是编译器的“管辖范围”。编译器为程序中的每个“数据单元”安排在适当的位置上。但是C语言的一个特点就是太灵活，太强大，它允许你干预“内存对齐”。如果你想了解更加底层的秘密，“内存对齐”对你就不应该再透明了。

一、内存对齐的原因
大部分的参考资料都是如是说的：
1、平台原因(移植原因)：不是所有的硬件平台都能访问任意地址上的任意数据的；某些硬件平台只能在某些地址处取某些特定类型的数据，否则抛出硬件异常。
2、性能原因：数据结构(尤其是栈)应该尽可能地在自然边界上对齐。原因在于，为了访问未对齐的内存，处理器需要作两次内存访问；而对齐的内存访问仅需要一次访问。

二、对齐规则
每个特定平台上的编译器都有自己的默认“对齐系数”(也叫对齐模数)。程序员可以通过预编译命令#pragma pack(n)，n=1,2,4,8,16来改变这一系数，其中的n就是你要指定的“对齐系数”。

规则：
1、数据成员对齐规则：结构(struct)(或联合(union))的数据成员，第一个数据成员放在offset为0的地方，以后每个数据成员的对齐按照#pragma pack指定的数值和这个数据成员自身长度中，比较小的那个进行。
2、结构(或联合)的整体对齐规则：在数据成员完成各自对齐之后，结构(或联合)本身也要进行对齐，对齐将按照#pragma pack指定的数值和结构(或联合)最大数据成员长度中，比较小的那个进行。
3、结合1、2颗推断：当#pragma pack的n值等于或超过所有数据成员长度的时候，这个n值的大小将不产生任何效果。

三、试验
我们通过一系列例子的详细说明来证明这个规则吧!
我试验用的编译器包括GCC 3.4.2和VC6.0的C编译器，平台为Windows XP + Sp2。

我们将用典型的struct对齐来说明。首先我们定义一个struct：
#pragma pack(n) /* n = 1, 2, 4, 8, 16 */
struct test_t {
 int a;
 char b;
 short c;
 char d;
};
#pragma pack(n)
首先我们首先确认在试验平台上的各个类型的size，经验证两个编译器的输出均为：
sizeof(char) = 1
sizeof(short) = 2
sizeof(int) = 4

我们的试验过程如下：通过#pragma pack(n)改变“对齐系数”，然后察看sizeof(struct test_t)的值。

1、1字节对齐(#pragma pack(1))
输出结果：sizeof(struct test_t) = 8 [两个编译器输出一致]
分析过程：
1) 成员数据对齐
#pragma pack(1)
struct test_t {
 int a;  /* 长度4 < 1 按1对齐；起始offset=0 0%1=0；存放位置区间[0,3] */
 char b;  /* 长度1 = 1 按1对齐；起始offset=4 4%1=0；存放位置区间[4] */
 short c; /* 长度2 > 1 按1对齐；起始offset=5 5%1=0；存放位置区间[5,6] */
 char d;  /* 长度1 = 1 按1对齐；起始offset=7 7%1=0；存放位置区间[7] */
};
#pragma pack()
成员总大小=8

2) 整体对齐
整体对齐系数 = min((max(int,short,char), 1) = 1
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 8 /* 8%1=0 */ [注1]

2、2字节对齐(#pragma pack(2))
输出结果：sizeof(struct test_t) = 10 [两个编译器输出一致]
分析过程：
1) 成员数据对齐
#pragma pack(2)
struct test_t {
 int a;  /* 长度4 > 2 按2对齐；起始offset=0 0%2=0；存放位置区间[0,3] */
 char b;  /* 长度1 < 2 按1对齐；起始offset=4 4%1=0；存放位置区间[4] */
 short c; /* 长度2 = 2 按2对齐；起始offset=6 6%2=0；存放位置区间[6,7] */
 char d;  /* 长度1 < 2 按1对齐；起始offset=8 8%1=0；存放位置区间[8] */
};
#pragma pack()
成员总大小=9

2) 整体对齐
整体对齐系数 = min((max(int,short,char), 2) = 2
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 10 /* 10%2=0 */

3、4字节对齐(#pragma pack(4))
输出结果：sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程：
1) 成员数据对齐
#pragma pack(4)
struct test_t {
 int a;  /* 长度4 = 4 按4对齐；起始offset=0 0%4=0；存放位置区间[0,3] */
 char b;  /* 长度1 < 4 按1对齐；起始offset=4 4%1=0；存放位置区间[4] */
 short c; /* 长度2 < 4 按2对齐；起始offset=6 6%2=0；存放位置区间[6,7] */
 char d;  /* 长度1 < 4 按1对齐；起始offset=8 8%1=0；存放位置区间[8] */
};
#pragma pack()
成员总大小=9

2) 整体对齐
整体对齐系数 = min((max(int,short,char), 4) = 4
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 12 /* 12%4=0 */

4、8字节对齐(#pragma pack(8))
输出结果：sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程：
1) 成员数据对齐
#pragma pack(8)
struct test_t {
 int a;  /* 长度4 < 8 按4对齐；起始offset=0 0%4=0；存放位置区间[0,3] */
 char b;  /* 长度1 < 8 按1对齐；起始offset=4 4%1=0；存放位置区间[4] */
 short c; /* 长度2 < 8 按2对齐；起始offset=6 6%2=0；存放位置区间[6,7] */
 char d;  /* 长度1 < 8 按1对齐；起始offset=8 8%1=0；存放位置区间[8] */
};
#pragma pack()
成员总大小=9

2) 整体对齐
整体对齐系数 = min((max(int,short,char), = 4
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 12 /* 12%4=0 */

5、16字节对齐(#pragma pack(16))
输出结果：sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程：
1) 成员数据对齐
#pragma pack(16)
struct test_t {
 int a;  /* 长度4 < 16 按4对齐；起始offset=0 0%4=0；存放位置区间[0,3] */
 char b;  /* 长度1 < 16 按1对齐；起始offset=4 4%1=0；存放位置区间[4] */
 short c; /* 长度2 < 16 按2对齐；起始offset=6 6%2=0；存放位置区间[6,7] */
 char d;  /* 长度1 < 16 按1对齐；起始offset=8 8%1=0；存放位置区间[8] */
};
#pragma pack()
成员总大小=9

2) 整体对齐
整体对齐系数 = min((max(int,short,char), 16) = 4
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 12 /* 12%4=0 */

四、结论
8字节和16字节对齐试验证明了“规则”的第3点：“当#pragma pack的n值等于或超过所有数据成员长度的时候，这个n值的大小将不产生任何效果”。另外内存对齐是个很复杂的东西，上面所说的在有些时候也可能不正确。呵呵^_^

[注1]
什么是“圆整”？
举例说明：如上面的8字节对齐中的“整体对齐”，整体大小=9 按 4 圆整 = 12
圆整的过程：从9开始每次加一，看是否能被4整除，这里9，10，11均不能被4整除，到12时可以，则圆整结束。

相关文章：
1. 也谈内存对齐(续)
2. 三谈内存对齐－背后的故事
3. 四谈内存对齐