MISRA C:2012 Deviations page contains rule-number mismatches vs. the official standard

[wosayttn]

Description

While reviewing the MISRA-C Deviations documentation for CMSIS-Core (Cortex-M) (checked against v6.2.0, page: Core/coreMISRA_Exceptions_pg.html, we noticed several discrepancies between the listed Rule IDs and the official MISRA C:2012 standard rule index. These mismatches cause confusion when mapping the documented deviations onto automated static analysis tool configuration (e.g. Cppcheck --suppress-rules) and when producing MISRA compliance reports for downstream projects.

---

Identified Discrepancies

1. Rule 1.3 Mismatch (Macro Operators # / ##)

• CMSIS Doc: Rule 1.3, multiple use of '#/##' operators in macro definition
• Official MISRA C:2012:
  • Rule 1.3 is "There shall be no occurrence of undefined or critical unspecified behaviour."
  • The use of # and ## preprocessor operators is officially covered by Rule 20.10 ("The # and ## preprocessor operators should not be used") — which the same page already lists separately, so this deviation is effectively duplicated under two different rule numbers, one of which is incorrect.

2. Rule 11.6 Mismatch (Integer-to-Pointer Cast)

• CMSIS Doc: Rule 11.6, cast from unsigned long to pointer
• Official MISRA C:2012:
  • Rule 11.6 is "A cast shall not be performed between pointer to void and an arithmetic type."
  • A cast from unsigned long to a pointer is an integer-to-pointer conversion, which is the topic of Rule 11.4 ("A conversion should not be performed between a pointer to object and an integer type") — already listed correctly immediately above it on the same page under its own entry.

3. Rule 14.4 Terminology Imprecision

• CMSIS Doc: Rule 14.4, conditional expression should have essentially Boolean type
• Official MISRA C:2012: Rule 14.4 specifically states "The controlling expression of an if statement and the controlling expression of an iteration-statement shall have an essentially Boolean type."
• The rule number itself is correct here; only the paraphrase ("conditional expression") is imprecise and resembles legacy MISRA C:2004 Rule 13.2 phrasing rather than the 2012 wording. Listed separately from items 1/2/4 since it is a wording issue, not a rule-number misattribution.

4. Rule 21.1 / 21.2 Description Inaccuracy

• CMSIS Doc: Rules 21.1 and 21.2, reserved to the compiler
• Official MISRA C:2012:
  • Rule 21.1: "#define and #undef shall not be used on a reserved identifier or reserved macro name."
  • Rule 21.2: "A reserved identifier or macro name shall not be declared."
• The page already cites both rule numbers, but summarizes them jointly under one generic description ("reserved to the compiler"), without distinguishing which specific requirement of each rule (21.1's restriction on #define/#undef usage vs. 21.2's restriction on declaring reserved names) applies to which CMSIS-Core usage. This loses the specific compliance context needed when mapping deviations to per-rule static-analyzer suppressions.

---

Impact

Developers attempting to mirror CMSIS-Core's documented MISRA deviations into project-level static analysis suppression configuration (e.g. Cppcheck's --suppress-rules, or similar tool rule-configuration files) may misconfigure their tools, because several Rule IDs in the documentation do not map strictly to the corresponding MISRA C:2012 standard rule text. In particular, items 1 and 2 above risk suppressing the wrong rule number project-wide, silently masking real violations of the actual Rule 1.3 / 11.6 topics that were never intended to be deviated.

---

Suggested Action

Update the MISRA-C Deviations section to:

• Reflect the exact official MISRA C:2012 rule titles for each listed entry.
• Remap the #/## macro-operator deviation from Rule 1.3 to Rule 20.10 (removing the duplicate/incorrect 1.3 entry).
• Remap the "cast from unsigned long to pointer" deviation from Rule 11.6 to Rule 11.4 (merging with the existing 11.4 entry, since they describe the same underlying conversion).
• Optionally refine the Rule 14.4 wording to match the official "controlling expression of an if statement / iteration-statement" phrasing.
• Split the combined "Rules 21.1 and 21.2, reserved to the compiler" bullet into two entries (or clarify per-rule) so readers can tell which CMSIS-Core usage pattern violates which specific rule requirement.