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.