3

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

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

由于此规则，是否有某种手动检查列表？

4

2 回答 2

2

First of all, the standard definition of implementation-defined behavior is: specific behavior which the compiler must document. So you can always refer to the compiler documentation whenever there is a need to document how a certain implementation-defined behavior is implemented.

What's left to you to do then is to document where the code relies on implementation-defined behavior. This is preferably done in source code comments.

Spontaneously, here are the most important things which you need to look for in the code. The list is not including those cases that are already covered by other MISRA rules (for example signedness of char).

  • The size of all the integer types. The size of int being most important, as it determines which type that is given to integer literals, C "boolean" expressions, implicitly promoted integers etc etc.
  • Obscure integer formats that aren't standard two's complement.
  • Any reliance on endianess.
  • The enum type format.
  • The floating point format.
  • Pointer to integer conversions, in case they are obscure on the given system.
  • Behavior of function inlining and the register keyword, if these are used.
  • Alignment issues including struct padding. Reliance on the size of a struct/union.
  • #include paths, in case they are obscure. Particularly if they are absolute and not relative.
  • Bitwise operators mixed with signed types (in most cases this is a bug or design mistake).
于 2015-09-09T11:54:07.553 回答
2

MISRA-C is primarily concerned with avoiding unpredictable behavior in the C language, those “traps and pitfalls” (such as undefined and unspecified behavior) all C developers should be aware of that a compiler will not always warn you about. This includes implementation-defined behavior, where the C standard specifies the behavior of certain constructs after compilation can vary. These tend to be less critical from a safety point of view, provided the compiler documentation describes its intended behavior as required by the standard.

That is, for each specific compiler the behavior is well-defined, but the concern is to assure the developers have verified this, including documenting language extensions, known bugs in the compiler (and build chain) and workarounds.

Although it is possible to manually check C code fully for MISRA-C compliancy, it is not recommended. The guidelines were developed with static analysis tools in mind. Not all guidelines can be fully checked by tools, but the better MISRA-C tools (be careful in your evaluations, there are not many “good” ones), will at least assist where it can identify automatically where code relies on implementation-specific behavior. This includes all the checks required in Rule 3.1., where implementation-defined behavior cannot be completely checked by a tool, then a manual review will be required.

Also, if you are starting a new MISRA-C project, I highly recommend referring to MISRA-C:2012, even if you are required to be MISRA-C:2004 compliant. Having MISRA-C:2012 around helps, because it has clarified many of the guidelines, including additional rationale, explanations and examples. The standard (which can be obtained at misra-c.com ) lists the C90 and C99 implementation-defined behaviors that are considered to have the potential to cause unintended behavior. This may or may not overlap with guidelines that address implementation-defined behaviors that MISRA-C is specifically concerned about.

于 2015-09-07T12:39:18.470 回答