This project C source files use MISRA C 2012 guidelines as underlying coding standard.
For MISRA validation, the project uses cppcheck. Cppcheck covers almost all the MISRA C 2012 rules. Including the amendments. Together with a C compiler flags we get full coverage.
The source code has the following deviations from MISRA C 2012:
| Rule | Category | Rationale for Skipping |
|---|---|---|
| [11.5]: A Conversion Should Not Be Performed from Pointer to void into Pointer to Object | Advisory | In our project, conversions from void * to specific object pointers are utilized in the context of generic data handling functions and callback mechanisms. This approach is central to implementing polymorphism in C, allowing us to write modular, reusable code that operates on various data types. Each conversion is carefully controlled and validated to ensure type correctness and safety. The use of void * pointers is confined to specific, well-documented interfaces where the actual data type is known and checked before dereferencing. This strategy allows for the flexibility required by our design patterns while mitigating the risks typically associated with such conversions. Type safety is ensured through rigorous testing and code reviews focused on these critical sections of the codebase. |
| [15.5]: A function should have a single point of exit at the end | Advisory | Early returns can reduce the need for nested conditional statements, making the code more straightforward and easier to read. The intent behind using an early return is to handle edge cases or preconditions at the beginning of the function, allowing the main function logic to remain unindented and clear. |
| [21.3]: The memory allocation and deallocation functions of <stdlib.h> shall not be used | Required | The nature of our software library requires managing a dynamic and potentially large number of objects. Users have the flexibility to create objects at runtime, and the exact number cannot be determined beforehand. Static allocation or using fixed-sized memory pools would restrict the functionality and limit the library's utility. Clear documentation instructs users on proper object lifecycle management, emphasizing the importance of deallocating objects when they are no longer needed. |
| [21.6]: The Standard Library input/output functions shall not be used | Style | The use of standard library input/output functions, specifically snprintf, is deemed necessary for dynamic error message formatting within the library. This functionality is critical for providing meaningful runtime diagnostics and cannot be efficiently replicated with static error messages or significantly simplified error reporting mechanisms. The implementation confines the use of snprintf to controlled environments where buffer sizes are strictly managed, and format string contents are known and verified. |