This document describes instances in which the code deviates from the MISRA C:2012 guidelines, categorized as Required. In accordance with Section 5.4 of the MISRA C:2012 guidelines, the report includes the following information for each deviation:
Functions shall not call themselves, either directly or indirectly. The rationale for MISRA C:2012 Rule 17.2 is that recursion carries with it the danger of exceeding available stack space, which can lead to a serious failure. Unless recursion is very tightly controlled, it is not possible to determine before execution what the worst-case stack usage could be.
This deviation is specific for single instances within individual files.
Certain algorithms are naturally implemented most efficiently and with the most clarity using recursion.
The recursive functions operate on a fixed-size data set determined by a well-defined rule set from the Unicode consortium.
Non-compliance with Rule 17.2, in this specific case, would not lead to any adverse consequences as the recursion is well-controlled and operates within known constraints.
The memory allocation and deallocation functions of <stdlib.h> shall not be used.
The rationale for MISRA C:2012 Rule 17.2 is that Use of dynamic memory allocation and deallocation routines provided by The Standard Library can lead to undefined behavior.
For example: memory that was not dynamically allocated is subsequently freed, a pointer to freed memory is used in any way, and accessing allocated memory before storing a value into it.
This deviation applies to the whole project.
Dynamic memory allocation is utilized where necessary to request additional memory from the host system to perform operations and execute algorithms. The implementation of memory allocation is considered essential for meeting project requirements.
The code has a comprehensive test suite with 100% branch coverage. It is tested with memory, address, and undefined behavior sanitizers, as well as memory leak detection tools. Consumers of the code can also disable the Standard Library allocators or replace them with their own custom implementation if necessary.
While the implementation is thoroughly tested, failure to comply with Rule 21.3 could lead to undefined behavior, such as memory leaks or invalid memory access, if defects are present in the implementation.