MISRA-C Standard
Introduction
The project checks for MISRA-C violations and cautions in the code base by running the Eclair MISRA-C compliance tool as part of our CI process. The results for the daily job can be found at TF-M Eclair daily CI pipeline.
The project, is not fully MISRA-C compliant. However, it aims to be MISRA-C-friendly by:
Avoiding the introduction mandatory MISRA-C violations and cautions.
Running regular checks on the code base.
Analysing and documenting violations and cautions prompted by the Eclair MISRA-C static analyser. This can be useful for downstream consumer looking for MISRA-C compliance.
While the project’s intention is to keep violations and cautions to a minimum, it will not block new features, bug fixes, or improvements even if they introduce difficult-to-resolve cautions or violations. Currently, the project is not equipped with necessary fast-feedback-loop tooling to inform contributors about the MISRA-C violations/cautions they introduce. The project welcomes suggestions and contributions to better align with the MISRA-C standard.
Note
In this document, Caution refers to a caution report generated by Eclair MISRA-C static analyser.
Update schedule
The analysis table for mandatory rules will be updated with every release. Currently, the table is up-to-date for release v2.2.0.
Assessment of mandatory MISRA-C rules violation and cautions
The following table presents an analysis of the violations and cautions of mandatory MISRA-C:2012 rules report by Eclair.
The reported violations cannot be easily resolved with the current code structure and are discussed further in the table. The project is not actively prioritizing their resolution; however, as mentioned earlier, it welcomes suggestions and contributions from the community.
The community should proactively address any cautions that can be reasonably resolved. However, if resolving a caution does not positively affect code quality and readability, it may be safely ignored.
MISRA-C rule Mandatory |
Error Type |
Rule definition |
Explanation |
|---|---|---|---|
Rule 9.1 |
Caution |
The value of an object with automatic storage duration shall not be read before it has been set |
Cautions are due to the objects not being explicitly initialised during declaration. In some of the cases the address of the object is passed to a function to retrieve required value which gives the appearance that the object is used uninitialized. |
Rule 17.4 |
Violation |
All exit paths from a function with non-void return type shall have an explicit ‘return’ statement with an expression |
All violations are exactly the same case of having a naked function with no C return statement. This cannot be resolved due to the body of the function being written in assembly. |
Rule 21.17 |
Caution |
Use of the string handling functions from <string.h> shall not result in accesses beyond the bounds of the objects referenced by their pointer parameters |
Currently seen with tfm_arch_init_context. It is used to clear the memory (stack) to be used to store program context (as part of the context initialisation). Remember, stack grows downwards - hence, pointer is decremented in the implementation. |
Rule 21.18 |
Caution |
The size_t argument passed to any function in <string.h> shall have an appropriate value |
Functions in TF-M use <string.h> functions with buffers/objects passed in by the caller. The functions suspected by Eclair have been double checked for verifying size of buffer/object before using them. |
List of required MISRA-C rules violation and cautions
The list of required MISRA-C rules violations can be found in TF-M Eclair daily CI pipeline -> Last Successful Artefacts -> index.html -> Report by issue strictness (Mandatory/Required/Advisory) (violations)
SPDX-License-Identifier: BSD-3-Clause
SPDX-FileCopyrightText: Copyright The TrustedFirmware-M Contributors