Appendix 1 - Phoenix MISRA C Profile

MISRA C 2023 rule headlines can be accessed on MISRA official git repository For detailed information a licensed copy of the MISRA C 2023 standard needs to be obtained from MISRA organization.

The following table lists the directives and rules of the MISRA C:2023 standard and their status within the Phoenix MISRA C Profile.

MISRA C Tailoring for Phoenix-RTOS development

MISRA C is a widely adapted guideline for C developers. Despite it automotive origin, MISRA C framework can be beneficial for other safety-critical industries like aerospace, aviation or medical. The primary objectives of this standard is elimination of undefined behavior, promotion of safety and consistent coding practices and effective reduction of reliability and predictability. For the low level development, especially development of operating system’s core functions, compliance to some rules might be either not possible or result in performance degradation. For example, MISRA C promotes portability by limiting the reliance on implementation-defined behavior. At the same time, it’s role of operating system to provide the implementation-agnostic interface and hide the low level interactions behind the hardware abstraction layer. Below a tailoring of MISRA C 2023 standard applicable to Phoenix-RTOS development process is presented. The tailoring has been prepared taking into considerations incorporation of MISRA C benefits without performance and productivity degradation and therefore following assumptions:

• All Advisory rules defined in the standard are treated as optional and will not be enforced by Phoenix Systems;

• Rules limiting access to hardware resources (e.g. register based interface to peripherals) will be disabled;

• Rules impacting pointer arithmetic performance and universal interfaces at kernel level will be disabled.

The compliance to MISRA C standard will be assessed using commercially available Code Static Analyzers, for example: Parasoft Cpptest, QA Systems QA MISRA, Synopsys Coverity. The tool should be configured to match the profile defined in table below.

It is also allowed to disable rule enforcement in the Code Static Analysis tool on case by case basis. Each case needs to be thoroughly reviewed by the developer and justification provided.

Column Descriptions

• ID: The official directive or rule identifier from the MISRA C:2023 standard.

• Category: The rule’s category as defined by the standard. By default, the Phoenix MISRA C Profile applies all Required and Mandatory rules.

• Applicability Change: Shows any deviation from the standard’s default applicability. Advisory rules may be ENABLED, while Required or Mandatory rules may be DISABLED. NO indicates no change.

• Applied: A YES/NO indicator of whether the rule is active in the Phoenix MISRA C Profile.

• Justification: Provides the justification for enabling or disabling a rule.

Phoenix MISRA C Profile

ID	Category	Applicability Change	Applied	Justification
Dir 1.1	Required	NO	YES
Dir 2.1	Required	NO	YES
Dir 3.1	Required	NO	YES
Dir 4.1	Required	NO	YES
Dir 4.2	Advisory	NO	NO
Dir 4.3	Required	NO	YES
Dir 4.4	Advisory	NO	NO
Dir 4.5	Advisory	NO	NO
Dir 4.6	Advisory	NO	NO
Dir 4.7	Required	NO	YES
Dir 4.8	Advisory	NO	NO
Dir 4.9	Advisory	NO	NO
Dir 4.10	Required	NO	YES
Dir 4.11	Required	NO	YES
Dir 4.12	Required	NO	YES
Dir 4.13	Advisory	NO	NO
Dir 4.14	Required	NO	YES
Dir 4.15	Required	NO	YES
Dir 5.1	Required	NO	YES
Dir 5.2	Required	NO	YES
Dir 5.3	Required	NO	YES
Rule 1.1	Required	NO	YES
Rule 1.2	Advisory	NO	NO
Rule 1.3	Required	NO	YES
Rule 1.4	Required	NO	YES
Rule 1.5	Required	NO	YES
Rule 2.1	Required	NO	YES
Rule 2.2	Required	NO	YES
Rule 2.3	Advisory	NO	NO
Rule 2.4	Advisory	NO	NO
Rule 2.5	Advisory	NO	NO
Rule 2.6	Advisory	NO	NO
Rule 2.7	Advisory	NO	NO
Rule 2.8	Advisory	NO	NO
Rule 3.1	Required	NO	YES
Rule 3.2	Required	NO	YES
Rule 4.1	Required	NO	YES
Rule 4.2	Advisory	NO	NO
Rule 5.1	Required	NO	YES
Rule 5.2	Required	NO	YES
Rule 5.3	Required	NO	YES
Rule 5.4	Required	NO	YES
Rule 5.5	Required	NO	YES
Rule 5.6	Required	NO	YES
Rule 5.7	Required	NO	YES
Rule 5.8	Required	NO	YES
Rule 5.9	Advisory	NO	NO
Rule 6.1	Required	NO	YES
Rule 6.2	Required	NO	YES
Rule 6.3	Required	NO	YES
Rule 7.1	Required	NO	YES
Rule 7.2	Required	NO	YES
Rule 7.3	Required	NO	YES
Rule 7.4	Required	NO	YES
Rule 7.5	Mandatory	NO	YES
Rule 7.6	Required	NO	YES
Rule 8.1	Required	NO	YES
Rule 8.2	Required	NO	YES
Rule 8.3	Required	NO	YES
Rule 8.4	Required	NO	YES
Rule 8.5	Required	NO	YES
Rule 8.6	Required	NO	YES
Rule 8.7	Advisory	NO	NO
Rule 8.8	Required	NO	YES
Rule 8.9	Advisory	NO	NO
Rule 8.10	Required	NO	YES
Rule 8.11	Advisory	NO	NO
Rule 8.12	Required	NO	YES
Rule 8.13	Advisory	NO	NO
Rule 8.14	Required	NO	YES
Rule 8.15	Required	NO	YES
Rule 8.16	Advisory	NO	NO
Rule 8.17	Advisory	NO	NO
Rule 9.1	Mandatory	NO	YES
Rule 9.2	Required	NO	YES
Rule 9.3	Required	NO	YES
Rule 9.4	Required	NO	YES
Rule 9.5	Required	NO	YES
Rule 9.6	Required	NO	YES
Rule 9.7	Mandatory	NO	YES
Rule 10.1	Required	NO	YES
Rule 10.2	Required	NO	YES
Rule 10.3	Required	NO	YES
Rule 10.4	Required	NO	YES
Rule 10.5	Advisory	NO	NO
Rule 10.6	Required	NO	YES
Rule 10.7	Required	NO	YES
Rule 10.8	Required	NO	YES
Rule 11.1	Required	NO	YES
Rule 11.2	Required	NO	YES
Rule 11.3	Required	DISABLED	NO	This rule is not applicable for the Phoenix-RTOS kernel source code, because casting between different types of pointers can not be avoided in the operating system implementation.
Rule 11.4	Advisory	NO	NO
Rule 11.5	Advisory	NO	NO
Rule 11.6	Required	DISABLED	NO	This rule is not applicable for the Phoenix-RTOS kernel source code, because casting between pointer to void and an arithmetic type can not be avoided inn the operating system implementation.
Rule 11.7	Required	NO	YES
Rule 11.8	Required	NO	YES
Rule 11.9	Required	NO	YES
Rule 11.10	Required	NO	YES
Rule 12.1	Advisory	NO	NO
Rule 12.2	Required	NO	YES
Rule 12.3	Advisory	NO	NO
Rule 12.4	Advisory	NO	NO
Rule 12.5	Mandatory	NO	YES
Rule 12.6	Required	NO	YES
Rule 13.1	Required	NO	YES
Rule 13.2	Required	NO	YES
Rule 13.3	Advisory	NO	NO
Rule 13.4	Advisory	NO	NO
Rule 13.5	Required	NO	YES
Rule 13.6	Required	NO	YES
Rule 14.1	Required	NO	YES
Rule 14.2	Required	NO	YES
Rule 14.3	Required	NO	YES
Rule 14.4	Required	NO	YES
Rule 15.1	Advisory	NO	NO
Rule 15.2	Required	NO	YES
Rule 15.3	Required	NO	YES
Rule 15.4	Advisory	NO	NO
Rule 15.5	Advisory	NO	NO
Rule 15.6	Required	NO	YES
Rule 15.7	Required	NO	YES
Rule 16.1	Required	NO	YES
Rule 16.2	Required	NO	YES
Rule 16.3	Required	NO	YES
Rule 16.4	Required	NO	YES
Rule 16.5	Required	NO	YES
Rule 16.6	Required	NO	YES
Rule 16.7	Required	NO	YES
Rule 17.1	Required	NO	YES
Rule 17.2	Required	NO	YES
Rule 17.3	Mandatory	NO	YES
Rule 17.4	Mandatory	NO	YES
Rule 17.5	Required	NO	YES
Rule 17.6	Mandatory	NO	YES
Rule 17.7	Required	NO	YES
Rule 17.8	Advisory	NO	NO
Rule 17.9	Mandatory	NO	YES
Rule 17.10	Required	NO	YES
Rule 17.11	Advisory	NO	NO
Rule 17.12	Advisory	NO	NO
Rule 17.13	Required	NO	YES
Rule 18.1	Required	NO	YES
Rule 18.2	Required	NO	YES
Rule 18.3	Required	NO	YES
Rule 18.4	Advisory	NO	NO
Rule 18.5	Advisory	NO	NO
Rule 18.6	Required	NO	YES
Rule 18.7	Required	NO	YES
Rule 18.8	Required	NO	YES
Rule 18.9	Required	NO	YES
Rule 18.10	Mandatory	NO	YES
Rule 19.1	Mandatory	NO	YES
Rule 19.2	Advisory	NO	NO
Rule 20.1	Advisory	NO	NO
Rule 20.2	Required	NO	YES
Rule 20.3	Required	NO	YES
Rule 20.4	Required	NO	YES
Rule 20.5	Advisory	NO	NO
Rule 20.6	Required	NO	YES
Rule 20.7	Required	NO	YES
Rule 20.8	Required	NO	YES
Rule 20.9	Required	NO	YES
Rule 20.10	Advisory	NO	NO
Rule 20.11	Required	NO	YES
Rule 20.12	Required	NO	YES
Rule 20.13	Required	NO	YES
Rule 20.14	Required	NO	YES
Rule 21.1	Required	DISABLED	NO	This rule is not applicable for Phoenix-RTOS kernel source code, because common identifiers are defined within its codebase and custom implementation of libc libphoenix.
Rule 21.2	Required	DISABLED	NO	This rule is not applicable for Phoenix-RTOS kernel source code, because common identifiers are defined within its codebase and custom implementation of libc libphoenix.
Rule 21.3	Required	NO	YES
Rule 21.4	Required	NO	YES
Rule 21.5	Required	DISABLED	NO	This rule is not applicable for the Phoenix-RTOS kernel source code, because <signal.h> is provided as part of custom implementation of libc libphoenix and therefore has defined behavior.
Rule 21.6	Required	NO	YES
Rule 21.7	Required	NO	YES
Rule 21.8	Required	NO	YES
Rule 21.9	Required	NO	YES
Rule 21.10	Required	DISABLED	NO	This rule is not applicable for the Phoenix-RTOS kernel source code, because date and time functions are provided as part of custom implementation of libc libphoenix and therefore have defined behavior.
Rule 21.11	Advisory	NO	NO
Rule 21.12	Required	NO	YES
Rule 21.13	Mandatory	NO	YES
Rule 21.14	Required	NO	YES
Rule 21.15	Required	NO	YES
Rule 21.16	Required	NO	YES
Rule 21.17	Mandatory	NO	YES
Rule 21.18	Mandatory	NO	YES
Rule 21.19	Mandatory	NO	YES
Rule 21.20	Mandatory	NO	YES
Rule 21.21	Required	NO	YES
Rule 21.22	Mandatory	NO	YES
Rule 21.23	Required	NO	YES
Rule 21.24	Required	NO	YES
Rule 21.25	Required	NO	YES
Rule 21.26	Required	NO	YES
Rule 22.1	Required	NO	YES
Rule 22.2	Mandatory	NO	YES
Rule 22.3	Required	NO	YES
Rule 22.4	Mandatory	NO	YES
Rule 22.5	Mandatory	NO	YES
Rule 22.6	Mandatory	NO	YES
Rule 22.7	Required	NO	YES
Rule 22.8	Required	NO	YES
Rule 22.9	Required	NO	YES
Rule 22.10	Required	NO	YES
Rule 22.11	Required	NO	YES
Rule 22.12	Mandatory	NO	YES
Rule 22.13	Required	NO	YES
Rule 22.14	Mandatory	NO	YES
Rule 22.15	Required	NO	YES
Rule 22.16	Required	NO	YES
Rule 22.17	Required	NO	YES
Rule 22.18	Required	NO	YES
Rule 22.19	Required	NO	YES
Rule 22.20	Mandatory	NO	YES
Rule 23.1	Advisory	NO	NO
Rule 23.2	Required	NO	YES
Rule 23.3	Advisory	NO	NO
Rule 23.4	Required	NO	YES
Rule 23.5	Advisory	NO	NO
Rule 23.6	Required	NO	YES
Rule 23.7	Advisory	NO	NO
Rule 23.8	Required	NO	YES