1################ 2MISRA-C Standard 3################ 4 5************ 6Introduction 7************ 8 9The project checks for MISRA-C violations and cautions in the code base by running the Eclair 10MISRA-C compliance tool as part of our CI process. The results for the daily job can be found at 11`TF-M Eclair daily CI pipeline`_. 12 13The project, is not fully MISRA-C compliant. However, it aims to be MISRA-C-friendly by: 14 15 - Avoiding the introduction mandatory MISRA-C violations and cautions. 16 - Running regular checks on the code base. 17 - Analysing and documenting violations and cautions prompted by the Eclair MISRA-C static 18 analyser. This can be useful for downstream consumer looking for MISRA-C compliance. 19 20While the project's intention is to keep violations and cautions to a minimum, it will not block new 21features, bug fixes, or improvements even if they introduce difficult-to-resolve cautions or 22violations. Currently, the project is not equipped with necessary fast-feedback-loop tooling to 23inform contributors about the MISRA-C violations/cautions they introduce. The project welcomes 24suggestions and contributions to better align with the MISRA-C standard. 25 26.. Note:: 27 In this document, `Caution` refers to a `caution report`_ generated by Eclair MISRA-C static 28 analyser. 29 30*************** 31Update schedule 32*************** 33 34The analysis table for mandatory rules will be updated with every release. Currently, the table is 35up-to-date for release v2.2.0. 36 37************************************************************ 38Assessment of mandatory MISRA-C rules violation and cautions 39************************************************************ 40 41The following table presents an analysis of the violations and cautions of mandatory MISRA-C:2012 42rules report by Eclair. 43 44The reported violations cannot be easily resolved with the current code structure and are discussed 45further in the table. The project is not actively prioritizing their resolution; however, as 46mentioned earlier, it welcomes suggestions and contributions from the community. 47 48The community should proactively address any cautions that can be reasonably resolved. However, if 49resolving a caution does not positively affect code quality and readability, it may be safely 50ignored. 51 52+------------------------+-------------+------------------------+-------------------------+ 53|MISRA-C rule Mandatory |Error Type |Rule definition |Explanation | 54+========================+=============+========================+=========================+ 55|Rule 9.1 |Caution |The value of an object |Cautions are due to the | 56| | |with automatic storage |objects not being | 57| | |duration shall not be |explicitly initialised | 58| | |read before it has been |during declaration. In | 59| | |set |some of the cases the | 60| | | |address of the object | 61| | | |is passed to a function | 62| | | |to retrieve required | 63| | | |value which gives the | 64| | | |appearance that the | 65| | | |object is used | 66| | | |uninitialized. | 67+------------------------+-------------+------------------------+-------------------------+ 68|Rule 17.4 |Violation |All exit paths from a |All violations are | 69| | |function with non-void |exactly the same case | 70| | |return type shall have |of having a naked | 71| | |an explicit 'return' |function with no C | 72| | |statement with an |return statement. This | 73| | |expression |cannot be resolved due | 74| | | |to the body of the | 75| | | |function being written | 76| | | |in assembly. | 77+------------------------+-------------+------------------------+-------------------------+ 78|Rule 21.17 |Caution |Use of the string |Currently seen with | 79| | |handling functions from |`tfm_arch_init_context`. | 80| | |`<string.h>` shall not |It is used to clear the | 81| | |result in accesses |memory (stack) to be | 82| | |beyond the bounds of the|used to store program | 83| | |objects referenced by |context (as part of the | 84| | |their pointer parameters|context | 85| | | |initialisation). | 86| | | |Remember, stack grows | 87| | | |downwards - hence, | 88| | | |pointer is decremented | 89| | | |in the implementation. | 90+------------------------+-------------+------------------------+-------------------------+ 91|Rule 21.18 |Caution |The `size_t` argument |Functions in TF-M use | 92| | |passed to any function |`<string.h>` functions | 93| | |in `<string.h>` shall |with buffers/objects | 94| | |have an appropriate |passed in by the | 95| | |value |caller. The functions | 96| | | |suspected by Eclair have | 97| | | |been double checked for | 98| | | |verifying size of | 99| | | |buffer/object before | 100| | | |using them. | 101+------------------------+-------------+------------------------+-------------------------+ 102 103***************************************************** 104List of required MISRA-C rules violation and cautions 105***************************************************** 106 107The list of required MISRA-C rules violations can be found in \ 108`TF-M Eclair daily CI pipeline`_ -> Last Successful Artefacts -> \ 109index.html -> Report by issue strictness (Mandatory/Required/Advisory) (violations) 110 111.. _TF-M Eclair daily CI pipeline: https://ci.trustedfirmware.org/view/TF-M/job/tf-m-eclair-daily/ 112.. _caution report: https://eclairit.com:3787/doc/index.html#term-caution-report 113 114-------------- 115 116*SPDX-License-Identifier: BSD-3-Clause* 117 118*SPDX-FileCopyrightText: Copyright The TrustedFirmware-M Contributors* 119