1# MISRA Compliance
2
3FreeRTOS-Kernel conforms to [MISRA C:2012](https://www.misra.org.uk/misra-c)
4guidelines, with the deviations listed below. Compliance is checked with
5Coverity static analysis version 2023.6.1. Since the FreeRTOS kernel is
6designed for small-embedded devices, it needs to have a very small memory
7footprint and has to be efficient. To achieve that and to increase the
8performance, it deviates from some MISRA rules. The specific deviations,
9suppressed inline, are listed below.
10
11Additionally, [MISRA configuration file](examples/coverity/coverity_misra.config)
12contains project wide deviations.
13
14### Suppressed with Coverity Comments
15To find the violation references in the source files run grep on the source code
16with ( Assuming rule 8.4 violation; with justification in point 1 ):
17```
18grep 'MISRA Ref 8.4.1' . -rI
19```
20
21#### Dir 4.7
22MISRA C:2012 Dir 4.7: If a function returns error information, then that error
23information shall be tested.
24
25_Ref 4.7.1_
26 - `taskENTER_CRITICAL_FROM_ISR` returns the interrupt mask and not any error
27    information. Therefore, there is no need test the return value.
28
29#### Rule 8.4
30
31MISRA C:2012 Rule 8.4: A compatible declaration shall be visible when an
32object or function with external linkage is defined.
33
34_Ref 8.4.1_
35 - pxCurrentTCB(s) is defined with external linkage but it is only referenced
36   from the assembly code in the port files. Therefore, adding a declaration in
37   header file is not useful as the assembly code will still need to declare it
38   separately.
39
40_Ref 8.4.2_
41 - xQueueRegistry is defined with external linkage because it is accessed by the
42   kernel unit tests. It is not meant to be directly accessed by the application
43   and therefore, not declared in a header file.
44
45#### Rule 8.6
46
47MISRA C:2012 Rule 8.6: An identifier with external linkage shall have exactly
48one external definition.
49
50_Ref 8.6.1_
51 - This rule prohibits an identifier with external linkage to have multiple
52   definitions or no definition. FreeRTOS hook functions are implemented in
53   the application and therefore, have no definition in the Kernel code.
54
55#### Rule 11.1
56MISRA C:2012 Rule 11.1: Conversions shall not be performed between a pointer to
57function and any other type.
58
59_Ref 11.1.1_
60 - The pointer to function is casted into void to avoid unused parameter
61   compiler warning when Stream Buffer's Tx and Rx Completed callback feature is
62   not used.
63
64#### Rule 11.3
65
66MISRA C:2012 Rule 11.3: A cast shall not be performed between a pointer to
67object type and a pointer to a different object type.
68
69_Ref 11.3.1_
70 - This rule prohibits casting a pointer to object into a pointer to a
71   different object because it may result in an incorrectly aligned pointer,
72   leading to undefined behavior. Even if the casting produces a correctly
73   aligned pointer, the behavior may be still undefined if the pointer is
74   used to access an object. FreeRTOS deliberately creates external aliases
75   for all the kernel object types (StaticEventGroup_t, StaticQueue_t,
76   StaticStreamBuffer_t, StaticTimer_t and StaticTask_t) for data hiding
77   purposes. The internal object types and the corresponding external
78   aliases are guaranteed to have the same size and alignment which is
79   checked using configASSERT.
80
81
82#### Rule 11.5
83
84MISRA C:2012 Rule 11.5: A conversion should not be performed from pointer to
85void into pointer to object.
86This rule prohibits conversion of a pointer to void into a pointer to
87object because it may result in an incorrectly aligned pointer leading
88to undefined behavior.
89
90_Ref 11.5.1_
91 - The memory blocks returned by pvPortMalloc() are guaranteed to meet the
92   architecture alignment requirements specified by portBYTE_ALIGNMENT.
93   The casting of the pointer to void returned by pvPortMalloc() is,
94   therefore, safe because it is guaranteed to be aligned.
95
96_Ref 11.5.2_
97 - The conversion from a pointer to void into a pointer to EventGroup_t is
98   safe because it is a pointer to EventGroup_t, which is returned to the
99   application at the time of event group creation for data hiding
100   purposes.
101
102_Ref 11.5.3_
103 - The conversion from a pointer to void in list macros for list item owner
104   is safe because the type of the pointer stored and retrieved is the
105   same.
106
107_Ref 11.5.4_
108 - The conversion from a pointer to void into a pointer to EventGroup_t is
109   safe because it is a pointer to EventGroup_t, which is passed as a
110   parameter to the xTimerPendFunctionCallFromISR API when the callback is
111   pended.
112
113_Ref 11.5.5_
114 - The conversion from a pointer to void into a pointer to uint8_t is safe
115   because data storage buffers are implemented as uint8_t arrays for the
116   ease of sizing, alignment and access.
117
118#### Rule 21.6
119
120MISRA C-2012 Rule 21.6: The Standard Library input/output functions shall not
121be used.
122
123_Ref 21.6.1_
124 - The Standard Library function snprintf is used in vTaskListTasks and
125   vTaskGetRunTimeStatistics APIs, both of which are utility functions only and
126   are not considered part of core kernel implementation.
127