Generating MISRA-C compliant code
The FMT tool was created with critical systems in mind and it is expected that in some projects the final generated code will be subject to strict coding standards like MISRA-C or MISRA-C++.
Most of the rules defined by these standards will be complied with as a result of how the core modeling language is constructed. For example, since dynamically allocated memory is not part of the modeling language, the rule forbidding its use is trivially met. Similarly, since no macros are produced by code generators, the rules concerning macros are automatically fulfilled as well. Undefined behaviour and run-time failures are avoided by means of formal correctness proofs. Still, in some other areas the modeling language and code generators do not impose any particular constraints and careless use can lead to models that are correct as far as FMT is concerned, but the generated code will not be coding-standard compliant - one example of such area is the limitation on the identifier length, which is defined by MISRA-C, but not controlled by FMT.
The following list highlights those rules that need additional attention if MISRA-C 2012 compliance is required.
- Dir 1.1 - FMT does not assume anything with regard to implementation-defined behaviour of the target language implementation. These behaviours need to be reviewed and consulted with the set of used language constructs.
- Dir 3.1 - it is the user’s responsibility to ensure traceability from code to documented requirements. Code-injected comments can be used as a possible mean to achieve this goal.
- Dir 4.5 and Rules 5.1-3, 5.6, 5.8-9 - translated identifiers are not always guaranteed to be unambiguous and unique; for example, with the default name translation rules for C code generator, symbols aB and A`b, even though considered distinct at the model level, will be both translated as “a_b” in the final C code. User-defined name translators and explicit lookup tables can introduce more name clashes, if not carefully constructed. Another point to consider is that names are not checked for length limits. It is the user’s responsibility to ensure that symbols are translated unambiguously and that compiler name limits are met.
- Rule 1.1 - FMT does not assume any implementation’s translation limits. For example, packages with extremely large number of definitions can lead to generated code that violates the target compiler limits. It is the user responsibility to verify that such limits are not overrun.
- Rules 2.3, 8.7, 8.9 - it is possible to create a model with unused type definitions or with functions that have only internal use or with package-level data objects that are used by only one function. The reason for this is that FMT does not assume that the model represents a complete target system - the generated code can be used in a wider context, together with files generated by other means or written manually. As such, these rules have a scope that is potentially larger than the scope of FMT in the given project and therefore should be verified in that wider context.
- Rule 3.1 - it is possible to inject comment delimiters within generated comment blocks and there are no checks to prevent this. Comments should be written reasonably and responsibly.
- Rule 14.3 - in the current version of FMT there are no checks to ensure that controlling expressions (for example, the While condition) are not invariant.
- Rule 16.4 - if the Switch statement is proven complete (that is, all enumeration values of the appropriate type are used as labels), the default branch is not required and no artificial branches are generated to meet such requirement. The reason for this is that incomplete Switch statements are always detected by the grammar reduction process, so defensive coding as proposed by this rule would be counter-productive; this rule can be therefore deviated.
Considering the fact that MISRA-C is one of the most rigorous standards that got wide industrial acceptance and that most other standards are to large extent inspired by it, compliance to those standards can be achieved as well, with similar points and issues to consider.
Previous: Customization, next: Grammar tags
See also Table of Contents.
