The importance of tailoring MISRA guidelines when working with existing code
One of the strongest points of BUGSENG is combining verification tools' development with advanced consulting services and training. Consider consulting. This often concerns assisting customers bring existing codebases into MISRA compliance (e.g., Zephyr and Xen). Working effectively with legacy code requires distinguishing those aspects of MISRA guidelines that relate to undefined or unspecified behavior (whose violations must all be considered carefully, one at a time) from those related to possible developer confusion (whose violations can often be discounted for legacy code).
Consider MISRA C Rule 10.1 (Operands shall not be of an inappropriate essential type) as an example: this places restrictions on the types that operands can have for each of the many C operators. Violating some restrictions might cause undefined behavior: this is the case for negative shift counts in shift operations. Other violations concern extremely fishy things, such as involving Booleans in arithmetic operations. And other violations concern possible developer confusion and/or implementation-defined behavior, such as using integers in a Boolean context (a pattern that is very common in legacy code) or performing bitwise operations on signed integers. As the number of Rule 10.1 violations in legacy code can be very high (of the order of tens of thousands for medium-sized embedded software projects), violations for code that is safe and reasonable should be deviated globally in the tool configuration. For example:
- the value-preserving conversions of integer constants are safe;
- shifting non-negative integers to the right is safe if the shift count is not too large;
- shifting non-negative integers to the left is safe if the result is still non-negative;
- bitwise logical operations on non-negative integers are safe even if the operands are of signed type;
- the implicit conversion to Boolean for logical operator arguments is safe;
- on architectures where signed integers are represented using two's complement (i.e., all the ones currently in use, to the point that this representation will be the only one supported by C23), the behavior of bitwise and, or, xor and negation on signed integers can be assumed to be known by all developers.
These kinds of considerations, in which we are deeply involved due to our consultancy services, allow us to validate and make the right choices for the ECLAIR Software Verification Platform®. In fact, we believe ECLAIR configurability makes it the ideal solution both for new and for legacy code. This is proven, on a daily basis and in ways that are visible to anyone, thanks to the open-source projects (e.g., TrustedFirmware) that have chosen ECLAIR as their static analysis platform.
White Paper: Jumpstarting MISRA compliance via the integration of static analysis into Open Source CI systems: best practices and key elements from TrustedFirmware.org
Over the last two years TrustedFirmware.org has integrated ECLAIR, BUGSENG’s MISRA tooling, into TrustedFirwmare’s Open CI as part of the validation efforts for both TF-A and TF-M.
Optimize your development strategy
If you are interested in optimizing your development strategy our experts are happy to discuss your projects' requirements and goals. For instance, every BUGSENG consultancy project starts with a NDA and a call to share the details of the project. We then run a preliminary analysis and create an initial assessment report. This is free of charge and can really help you get a picture of what you should focus on.