c - misra c 2004 "Implementation-defined behavior documented"规则 3.1 涵盖的问题

Question

在此规则中，您必须转到 ISO/IEC 9899:1990 附录 G 并研究每个实现定义行为的案例以记录它们。

确定要在代码中执行哪些手动检查是一项艰巨的任务。

是否有某种类型的手动检查列表需要根据此规则执行？

Answer 1

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 特别关注的实现定义行为的指南重叠。