MISRA C compliance: first rules now available

Sonar Updates
, , , ,
1

Hello dear C users,

After bringing you full MISRA C++:2023 coverage — all 179 guidelines — we are now investing in strict MISRA C compliance, with the same approach: precise, low-noise rules delivered inside your normal SonarQube workflow.

With SonarQube Server 2026.4, we are shipping the first batch of 36 MISRA C guidelines (35 rules and 1 directive), together with a dedicated MISRA C quality profile. Here is the initial set, organized by the MISRA C edition each guideline originates from. All of them are part of the consolidated MISRA C:2023 edition.

From MISRA C:2012 (33 guidelines)

  • Dir 4.4 — Sections of code should not be “commented out”
  • Rule 3.1 — The character sequences /* and // shall not be used within a comment
  • Rule 3.2 — Line-splicing shall not be used in // comments
  • Rule 4.1 — Octal and hexadecimal escape sequences shall be terminated
  • Rule 4.2 — Trigraphs should not be used
  • Rule 6.1 — Bit-fields shall only be declared with an appropriate type
  • Rule 6.2 — Single-bit named bit-fields shall not be of a signed type
  • Rule 7.1 — Octal constants shall not be used
  • Rule 7.3 — The lowercase character “l” shall not be used in a literal suffix
  • Rule 8.12 — Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique
  • Rule 10.1 — Operands shall not be of an inappropriate essential type
  • Rule 10.2 — Expressions of essentially character type shall not be used inappropriately in addition and subtraction operations
  • Rule 10.3 — The value of an expression shall not be assigned to an object with a narrower essential type or of a different essential type category
  • Rule 10.4 — Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category
  • Rule 10.5 — The value of an expression should not be cast to an inappropriate essential type
  • Rule 15.1 — The goto statement should not be used
  • Rule 15.2 — The goto statement shall jump to a label declared later in the same function
  • Rule 15.5 — A function should have a single point of exit at the end
  • Rule 15.7 — All if … else if constructs shall be terminated with an else statement
  • Rule 17.2 — Functions shall not call themselves, either directly or indirectly
  • Rule 17.8 — A function parameter should not be modified
  • Rule 20.2 — The ', " or \ characters and the /* or // character sequences shall not occur in a header file name
  • Rule 20.3 — The #include directive shall be followed by either a <filename> or "filename" sequence
  • Rule 20.4 — A macro shall not be defined with the same name as a keyword
  • Rule 20.5 — #undef should not be used
  • Rule 20.9 — All identifiers used in the controlling expression of #if or #elif preprocessing directives shall be #define’d before evaluation
  • Rule 20.10 — The # and ## preprocessor operators should not be used
  • Rule 20.11 — A macro parameter immediately following a # operator shall not immediately be followed by a ## operator
  • Rule 20.12 — A macro parameter used as an operand to the # or ## operators, which is itself subject to further macro replacement, shall only be used as an operand to these operators
  • Rule 20.13 — A line whose first token is # shall be a valid preprocessing directive
  • Rule 21.3 — The memory allocation and deallocation functions of <stdlib.h> shall not be used
  • Rule 21.5 — The standard header file <signal.h> shall not be used
  • Rule 21.9 — The Standard Library functions bsearch and qsort of <stdlib.h> shall not be used

Added in MISRA C:2012 Amendment 2 (1 guideline)

  • Rule 21.21 — The Standard Library function system of <stdlib.h> shall not be used

Added in MISRA C:2012 Amendment 3 (2 guidelines)

  • Rule 17.11 — A function that never returns should be declared with a _Noreturn function specifier
  • Rule 21.24 — The random number generator functions of <stdlib.h> shall not be used

Like our MISRA C++:2023 compliance rules, these are built to be accurate and low-noise, and they plug into the same MISRA workflow: compliance quality gates, deviation records, and in-IDE feedback so developers catch non-compliant code as they write it.

This is only the beginning. This is our first batch of MISRA C guidelines, and we will keep adding rules and directives on the way toward full coverage, as we did for MISRA C++:2023.

Availability: the MISRA C compliance rules and quality profile are available, like MISRA C++:2023, in SonarQube Server Enterprise Edition and above.

MISRA and MISRA C are registered trademarks of The MISRA Consortium Limited.

2 Likes
Sonar Community Roundup, July 18 - 24