The job of static analysis tools, when used to help software organizations comply with MISRA C, is to report violations. These violations come in a number of different categories and severities, the examples below are taken from MISRA-C:2012.
“Code Smells”
They are programming style rules in MISRA C that are there to improve the understanding of a program. Some people call them code smells. An example of such as rule is 2.3, “a project should not contain unused type declarations”, or rule 5.3 “identified declared in an inner scope shall not hide an identifier declared in an outer scope.” These violations are easily detected by static analysis tools and reported to the developer who can easily fix them.
Undefined Behavior
MISRA has a large set of rules against undefined behavior, detecting and fixing these types of code problems is more difficult. Examples of these types of defects are NULL pointer dereference, a buffer overflow, or tainted data. These errors are much deeper and more dangerous but also have a large impact; leading to program crashes, security vulnerabilities and other nasty problems during run-time. GrammaTech CodeSonar is exceptionally good at finding these problems due to its data flow, control flow and abstract execution analysis.
Deviation Reports
Nevertheless, once a violation has been detected and reported, it needs to be addressed. This means it either needs to be fixed by the developer, or reviewed and marked as an approved deviation. Both these workflows are easy to do using CodeSonar’s warning tracking mechanism.
CodeSonar uses a unique identifier to track for every warning it generates. This identifier does not change if the code changes. In other words, if there is a warning against rule X on line Y in file foo.c, then that warning gets a unique id. If the developer adds or removes lines before line Y, then that id will remain the same.
Finding all the MISRA violations is an easy query resulting in a prioritized list, prioritized by risk to the software system, or sorted by MISRA rule.
Managing Deviations
CodeSonar also allows the team to follow a simple process to assess these warnings. A developer can mark the warning as ‘Deviation Requested’. The wider team can then ask for a list of warnings with ‘Deviation Requested’ and either approve or reject them. An approved deviation can be marked with ‘Deviation Approved’ and can be used to create a list of approved MISRA deviations in the project, complete with the information about the requester and the approver of the deviation. A permanent record of these deviations is critical if audits are needed during product compliance testing or certification.
Introducing CodeSonar deviation management for MISRA compliance, into a new or existing project can literally be done in a matter of minutes, as many of our customers have experienced. Another way that CodeSonar helps customers manage functional safety requirements in their programs.
