SELinux是Security Enhanced Linux的缩写。望文生义的时候还以为是关于黑客啊、攻击啊、漏洞啊之类的事情，这两天在读《SELinux by example》的时候才明白，原来这个东东竟然是用来对付程序员的，准确的说，是为了防止由于程序员的疏忽或错误对系统造成不可预料的伤害。
书中的例子是关于文件/etc/passwd，碰巧同时在读的《Mastering Perl》的第三章Secure Programming Techniques中也用这个文件举例。后者主要是说明处理外部数据时要格外当心，否则可能导致泄露系统信息。然而，要求每个程序员在写程序的时候都要打起120分的精力来注意安全问题是不现实的，总有这样那样的原因导致安全问题被有意无意的忽略。而且，与其让每个程序单独的考虑安全问题，不如将其放在一个集中的地方，就如同SELinux那样，使用各种规则来保证每个程序只能访问特定的系统资源，以及每种系统资源只能被特定的程序访问。
通俗地讲，即使某些应用程序在运行时被提升为具有root权限以访问某些系统资源，但是由于SELinux的存在，一个具有root权限的程序也不意味着它可以访问任何系统资源，相反，它只能访问那些被SELinux规则允许的系统资源，这样就避免了由于程序员的疏忽或错误而对系统造成伤害。
看到这个我想起一个问题，当然，也是看到你去年的计划总结，呵呵。编译器的优化能力。
以GCC为例，加了-O3后，是否有可能发生下面的情况？
——————–
double i=0.0;
..
..
有if语句判断后，对i赋值（不为0）；
..
此后，
通过if语句控制，有很多用到1/i的地方，并且i不再发生变化。
——————–
那么，是否有可能GCC将1/i的计算提前，提前至“有if语句判断后，对i赋值；”的后面，以便后续使用的时候不重复计算？
之所以有这个问题，是在程序里面，我开始对i赋值为0，但后续的计算里面，通过if语句的判断，都没有真正的执行（这也是我想要的），但却报告有算术异常。但如果将前面的i的赋值去掉，仅声明它，就没有这个警告了。
我试图看汇编的结果，无奈，不太懂汇编，没看明白。而且我发现，这个函数如果仅有
double i;
和
double i=0.0;
的差别时，汇编的结果有很大的不同。
如果你说的算术异常是在运行时发生，那么可以尝试关闭优化选项重新编译运行，如果此时没有异常发生，那么是gcc的优化有问题，否则是你的程序的问题。
如果是编译时的错误（应该不会是错误）或警告，那么先不要理它，运行了再说，如果运行没问题，那么最好修改你的程序结构，把这个警告消除掉。
是否给i赋值确实对生成代码有很大影响，有了常数，就可以做常量传播，有可能对程序结构带来很大的变化。