Skip to main content

Table 6 Extract of the walkthrough report on MISRA directive. Table’s columns contain in order: directive number, directive class, description of the rule and auditor’s comment about the rule

From: Development and validation of a safe communication protocol compliant to railway standards

Directive Class Description Comment
1.1 Mandatory Any implementation-defined behavior on which the output of the program depends shall be documented and understood The description of the implementations Followed a pattern that made it easier to understand its content and goals
2.1 Mandatory All source files shall compile without any compilation errors No errors or warnings during compilation.
3.1 Mandatory All code shall be traceable to documented requirements Most of the requirements names are reused in the code; it is easy to trace everything to its original requirements.
4.4 Advisory Sections of code should not be “commented out” No commented code found.
4.5 Advisory Identifiers in the same name space with overlapping visibility should be typographically unambiguous Identifiers are self-explanatories, no ambiguity found.
4.6 Advisory Typedefs that indicate size and signedness should be used in place of the basic numerical types Functions use raw integers to indicate a state/type.
4.7 Mandatory If a function returns error information, then that error information shall be tested There is error handling in all the functions related to the protocol, haven’t seen any tests to prove their efficiency.
4.8 Advisory If a pointer to a structure or union is never dereferenced within a translation unit, then the implementation of the object should be hidden Pointers have their object implementation hidden.
4.9 Advisory A function should be used in preference to a function-like macro where they are interchangeable Function-like macros are rare in the code
4.12 Mandatory Dynamic memory allocation shall not be used Not found.