sh一在建楼盘轰然倒塌

事情发生在早上5：40分左右。

行人车辆请注意,飞机就要开过来了！

请在拦木外等候，不要抢行，不要翻栏杆！

Linux代码淬火工具

介绍用来提高Linux应用程序安全性和可靠性的开源工具和代码追踪技术。
一、源代码检查工具
在软件开发过程中，我们可以利用源码检查工具来找出常见的编程错误以及安全漏洞。这些工具用起来并不复杂，下面介绍splint和flawfinder这两款源码检查工具的使用方法。
splint是一款静态源代码检查工具，能对源代码进行全面的分析。对于没有注释的源代码，可以使用-weak选项：
splint -weak *.c -I./inc
其中，./inc是头文件所在的子目录。此外，Splint还支持标准检查模式（选项-standard），若要进行中等强度检查则使用选项-checks，若使用选项-strict则进行最严格的检查。
flawfinder也是一款用来寻找源代码错误的静态分析工具。通过该工具提供错误消息，开发人员可以更快的找到错误所在。请看下面的例子：
$ flawfinder test.c
test.c:11: [2] (buffer) char:
Statically-sized arrays can be overflowed. Perform bounds
checking, use functions that limit length, or ensure that
the size is larger than the maximum possible length.
$
本例中，flawfinder给出了一个提示，指出静态尺寸的数组可能被恶意利用的潜在危险。
除了上面介绍的splint和flawfinder这两款工具外，还有RATS（一款安全审计工具）以及ITS4（静态漏洞扫描工具）等工具可用。但需要
注意的是，虽然这些工具能够分担一部分工作，但却无法完全替代人类。因为工具在发现漏洞的同时，也可能遗漏安全漏洞。

二、代码跟踪技术
我们知道，strace工具通常是用来追踪系统调用的，实际上，它还可以作为间接的源代码审计工具。从系统调用的角度来跟踪应用程序的执行，可以让我们了解到Linux应用程序的底层操作，借助这些低层操作我们可以更好的理解我们的源代码。
在下面的例子中，有多处违反了我们前面讨论的代码淬火原则，现在我们展示如何利用strace来进行调试。
#include <unistd.h>
#include <fcntl.h>
#define MAX_BUF 128
int main()
{
int fd;
char buf[MAX_BUF+1];
fd = open( "myfile.txt", O_RDONLY );
read( fd, buf, MAX_BUF );
printf( "read %s\n", buf );
close( fd );
}
我们注意到，上面的代码的第11行，即：fd = open( "myfile.txt", O_RDONLY
);
试图打开一个称为myfile.txt的文件，但事前并没有检查该文件是否业已存在。在这种情况下执行该程序的话，会导致无法预测的结果：
$ gcc -o bad bad.c
$ ./bad
read @?8Z@
$
看看，这样的结果是你没料到的吧。所以，先让我们利用strace来看看到底发生了什么。注意，下面的输出已经作了删减，但重要的信息都保留下来了：
$ strace ./bad
execve("./bad", ["./bad"], [/* 20 vars */]) = 0
uname({sys="Linux", node="camus", ...}) = 0
...
open("myfile.txt", O_RDONLY) = -1 ENOENT ( No such file or
directory)
read(-1, 0xbfffef20, 128) = -1 EBADF (Bad file descriptor)
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x40017000
write(1, "read \300\357\377\2778Z\1@\n", 14read /à???8z@
) = 14
close(-1) = -1 EBADF (Bad file descriptor)
munmap(0x40017000, 4096) = 0
exit_group(-1) = ?
$
执行程序后，我们看到用来启动该程序的系统调用是execve()；不久又调用了open()，该系统调用对应于代码中的第11行。并且我们看到系统调用
open()的右边的返回值是-1，并指出错误"ENOENT ( No such file or
directory)"，即不存在这个文件或目录。换句话说，这是在告诉我们需要先建立文件。此外，系统调用read()也以失败而告终，它的错误是非法
的文件描述符，因为open调用失败了。
strace工具不仅用来帮助理解有源代码的程序的行为，而且也对于没有源代码的程序也同样有效。因为，透过对系统调用的观察，我们能够在二进制级别来理解程序的行为。

三、小结
古人云，工欲善其事，必先利其器。借助于上文介绍的代码淬火方面的编码知识，用来提高Linux应用程序安全性和可靠性的调试工具，相信读者能够更快更好开发出安全可靠的高品质软件来。

编程利器——splint工具

到底需不需要编译器之外的独立的静态代码检查工具呢？这个问题'仁者见仁，智者见智'。但是有一个结论我想大家都会认可，那就是越是在开发周期早期发现的
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程序的检查。