[参考译文] 编译器：bool 和 trap 表示法？

我们正确地将变量声明为_Bool (实际上、我们在#include stdbool.h 之后将其声明为"bool)、这是因为我们的意图是它只会为0或1、并将其声明为 bool 表示该意图。

我们还认为我们喜欢这样的功能：对 bool 的赋值(包括向 bool 函数参数提供非 bool 整数)会自动将非零整数转换为1。  我们只是没有深入研究从 bool 读取数据时是否发生类似转换的问题。  这并不令人惊讶；只是我们没有真正理解、通过使用 C99标准_Bool / bool 类型、我们一直面临一个新类别的漏洞(陷阱表示)、而该类别在其他方面不存在。

其值设法为0x81的情况是一个错误。  (大概是我们的错误、但不一定；我们尚未跟踪它。)  无论我们使用哪种类型的变量、都需要对其进行修复。

但是、要使程序安全、不仅仅是找到所有错误并修复它们。  很难解释未定义的行为。  执行以下函数：

#ifdee_undefined_behavior
typedef unsigned char BOOL；
#else
typedef _bool BOOL；
#endif

void checkStatus (BOOL errorDetected)
｛
IF (错误检测)
handleError()；
其他
HandleSuccess()；
}

可以很容易地想象，开发人员或对等审校员可能会假定，无论 BOOL 是以何种方式定义的，在每次调用 checkStatus()时(但不是两者都定义！) 将调用 errorDetected ()或 handleSuccess()，而不管程序执行早期可能发生了什么类型的错误。

这当然是天真的。  C 语言中有超过一百种未定义的行为、更不用说堆栈损坏或其他严重的"外部"问题的可能性。  如果 handleError()和 handleSuccess()都没有被调用，或者两者都被调用，那么，这并不是发生未定义行为时可能发生的最糟糕的事情。

但是、将 BOOL 定义为_Bool 会增加一个额外的基本漏洞、当 BOOL 定义为 unsigned char 时、它不具有该漏洞。

(对于这种情况、使用 unsigned char 将允许我们添加断言检查以确认 errorDetected 始终为0或1。)

(我并不是说我们检测到 TI ARM 编译器以令人惊讶的方式编译了上述函数。  我们的实际惊喜是位字段。  我将对其进行一些简化、并将其添加到此线程中、就像 FYI 一样、如果有人有任何好奇、我接受编译器符合适用的 C 标准。)

-thx