【发布时间】：2015-12-02 21:50:11
【问题描述】：
在此规则中，您必须转到 ISO/IEC 9899:1990 附录 G 并研究每个实施定义的行为案例以记录它们。
确定要在代码中执行哪些手动检查是一项艰巨的任务。
由于这条规则，是否需要执行某种手动检查列表？
【问题讨论】：
-
通常我只是去我的编译器手册。在那里它必须指定它的所有实现定义的行为。有了它，应该很容易确定你必须查看的位置。
【发布时间】：2015-12-02 21:50:11
【问题描述】：
MISRA-C 主要关注的是避免 C 语言中不可预测的行为，所有 C 开发人员都应该意识到编译器不会总是警告您这些“陷阱和陷阱”（例如未定义和未指定的行为）。这包括实现定义的行为，其中 C 标准指定某些构造在编译后的行为可能会有所不同。从安全的角度来看，这些往往不太重要，前提是编译器文档描述了标准要求的预期行为。
也就是说，对于每个特定的编译器，行为都是明确定义的，但需要确保开发人员已经验证了这一点，包括记录语言扩展、编译器（和构建链）中的已知错误和解决方法。
虽然可以手动检查 C 代码是否完全符合 MISRA-C 合规性，但不建议这样做。该指南是在考虑静态分析工具的情况下制定的。并非所有指南都可以通过工具进行全面检查，但是更好的 MISRA-C 工具（在评估时要小心，没有很多“好”的工具），至少可以帮助它自动识别代码依赖于特定实现的地方行为。这包括规则 3.1 中要求的所有检查，如果实现定义的行为不能被工具完全检查，则需要手动审查。
另外，如果您正在开始一个新的 MISRA-C 项目，我强烈建议您参考 MISRA-C:2012，即使您需要符合 MISRA-C:2004。拥有 MISRA-C:2012 会有所帮助，因为它阐明了许多指南，包括额外的基本原理、解释和示例。该标准（可从 misra-c.com 获得）列出了被认为可能导致意外行为的 C90 和 C99 实现定义的行为。这可能与解决 MISRA-C 特别关注的实现定义行为的指南重叠，也可能不重叠。
【讨论】：
首先，实现定义行为的标准定义是：编译器必须记录的具体行为。因此，当需要记录如何某个实现定义的行为是如何实现时，您始终可以参考编译器文档。
接下来你要做的就是记录在哪里代码依赖于实现定义的行为。这最好在源代码 cmets 中完成。
以下是您需要在代码中查找的最重要的内容。该列表不包括其他 MISRA 规则已涵盖的情况（例如 char 的签名）。
- 所有整数类型的大小。
int的大小是最重要的，因为它决定了赋予整数文字、C“布尔”表达式、隐式提升整数等的类型。 - 非标准二进制补码的晦涩整数格式。
- 任何对字节序的依赖。
- 枚举类型格式。
- 浮点格式。
- 指向整数转换的指针，以防它们在给定系统上模糊不清。
- 函数内联的行为和
register关键字（如果使用的话）。 - 对齐问题，包括结构填充。依赖于结构/联合的大小。
-
#include路径，以防它们晦涩难懂。特别是如果它们是绝对的而不是相对的。 - 位运算符与有符号类型混合（在大多数情况下，这是错误或设计错误）。
【讨论】：