[译]CERT Secure Coding Standard — C语言安全编程规范(4)
11. 信号
| 规则/建议条目全称 | 例外 | 笔记 /备注/点评 |
| SIG00-C. 屏蔽由不可中断信号处理函数处理的信号 | POSIX标准建议使用sigaction()，废弃signal()。但sigaction()不是C99标准。 | |
| SIG01-C. 理解信号处理函数持久化相关的实现细节 | *nix平台上的信号处理函数一般是实现为“持久化”的，即除非显式的删除该信号处理函数，否则该信号处理函数会一直运行时有效。而Windows平台上则恰好相反，信号处理函数被执行一次后就会自动被删除。 | |
| SIG02-C. 避免使用信号机制来实现普通函数功能 | 从代码可安全移植的角度设计的本条建议。 | |
| SIG30-C. 在信号处理函数内部仅调用异步安全函数 | 查手册确定异步安全函数有哪些。 | |
| SIG31-C. 禁止在信号处理函数内部访问或修改共享对象 | 否则会导致竞争读写问题，引起数据状态的不一致。读写volatile sig_atomic_t类型变量则没有问题，读写其他类型变量的行为则是“未定义”的。 | |
| SIG32-C. 在信号处理函数内部禁止调用longjmp() | 本条规则和SIG30-C. 在信号处理函数内部仅调用异步安全函数是相关的。 | |
| SIG33-C. 禁止递归调用raise() | ||
| SIG34-C. 禁止在可中断信号处理函数内调用signal() | SIG34-EX1: 在支持持久化信号处理函数的平台上信号处理函数可以安全的修改自己的信号处理行为。 | 一个信号处理函数仅仅在其不需要是异步安全时可以嵌套调用signal()。 |
| SIG35-C. 禁止从SIGSEGV, SIGILL, 或SIGFPE的信号处理函数返回 | 否则会引起“未定义”行为。 |
12. 错误处理
| 规则/建议条目全称 | 例外 | 笔记 /备注/点评 |
| ERR00-C. 采用和实现一个一致和全面的错误处理策略 | ||
| ERR01-C. 使用ferror()而不是errno来检查文件流错误 | errno仅仅在某些库函数调用出错返回错误代码并会设置errno位时才有意义，并非所有的文件流操作操作都会设置errno。ferror()则是针对特定文件流是否操作出错的检查。 | |
| ERR02-C. 避免“带内”(in-band)错误指示符 | ERR02-EX1: 空指针是另一个in-band错误指示符的例子，但空指针不会引起任何副作用。
ERR02-EX2: 如果你能保证函数在执行过程中出错时绝不会继续执行(可以通过调用abort()或者longjmp()中断函数执行过程)，你的函数就可以返回in-band错误指示符。 |
所谓in-band，学过通信的都知道所谓“带内”信号和“带外”信号，in-band的含义就是所传递的信息会占用“正常”的传输通道资源。在C语言的标准库函数实现里大量的使用了in-band错误指示符，即函数的返回值在正常执行成功时会返回一些操作成功相关的变量值，函数执行出错时又利用返回值设置错误变量值。相当于函数的返回值在这里既是正常“返回结果”的传递通道，又是错误“返回结果”的传递通道。由于两种返回结果可能是不同的数据类型，因此函数在定义时可能会使用“兼容”数据类型，从而增加了函数调用者调用函数时的逻辑处理复杂度，可能会导致一些“二义性”或者“理解偏差”错误。 |
| ERR03-C. 调用TR24731-1标准定义的系列函数时使用运行时约束条件处理函数 | strcpy_s()就是TR24731-1定义的一个函数，所谓“运行时约束条件处理函数”就是指的调用set_constraint_handler_s()注册一个运行时约束条件违反处理函数。该条建议主要针对微软平台，*nix平台忽略该条建议应该问题不大。 | |
| ERR04-C. 选择一个合适的程序退出策略 | C99标
补充：综合编程 , 安全编程 ,
CopyRight © 2012 站长网 编程知识问答 www.zzzyk.com All Rights Reserved
部份技术文章来自网络， |
