JavaScript is not currently enabled, but is required for full CodeSonar manual search and browse functionality.

If you are viewing this file in your hub's Web GUI, enable JavaScript in your browser: you will also need it for GUI functionality.

If you opened this file directly from disk, your browser may be directly suppressing JavaScript functionality: certain browsers perform this suppression on local files (but not files delivered by web servers) for security reasons.

CodeSonar® 9.2p0 CONFIDENTIAL CodeSecure Inc

Checks for MISRA C Standards

The categories list for each CodeSonar warning includes any relevant MISRA C rule numbers.

A broader set of MISRA C correspondences is shown in Broad Mapping: MISRA C.

CSV tables of warning classes by MISRA C rule are provided in MisraC2025-mapping.csv, MisraC2023-mapping.csv, Misra2012-mapping.csv, and Misra2004-mapping.csv.

See also:



Introduction

CodeSonar includes a large number of warning classes that support checking for the following MISRA C standards.

See also:

The categories list for each CodeSonar warning includes any relevant MISRA rule numbers.

MISRA C:2025

The following table shows the CodeSonar warning classes that are associated with the guidelines in MISRA C:2025.

This table is also available in CSV format: MisraC2025-mapping.csv.

MisraC2025 Category Decidability Guideline TypeC Warning Classes
MisraC2025:1.1 The program shall contain no violations of the standard C syntax and constraints, and shall not exceed the implementation's translation limits Required Decidable Rule
MisraC2025:1.3 There shall be no occurrence of undefined or critical unspecified behaviour Required Undecidable Rule
MisraC2025:1.4 Emergent language features shall not be used Required Decidable Rule
MisraC2025:1.5 Obsolescent language features shall not be used Required Undecidable Rule
MisraC2025:2.1 A project shall not contain unreachable code Required Undecidable Rule
MisraC2025:2.2 A project shall not contain dead code Required Undecidable Rule
MisraC2025:2.3 A project should not contain unused type declarations Advisory Decidable Rule
MisraC2025:2.4 A project should not contain unused tag declarations Advisory Decidable Rule
MisraC2025:2.5 A project should not contain unused macro definitions Advisory Decidable Rule
MisraC2025:2.6 A function should not contain unused label declarations Advisory Decidable Rule
MisraC2025:2.7 A function should not contain unused parameters Advisory Decidable Rule
MisraC2025:2.8 A project should not contain unused object definitions Advisory Decidable Rule
MisraC2025:3.1 The character sequences /* and // shall not be used within a comment Required Decidable Rule
MisraC2025:3.2 Line-splicing shall not be used in // comments Required Decidable Rule
MisraC2025:4.1 Octal and hexadecimal escape sequences shall be terminated Required Decidable Rule
MisraC2025:4.2 Trigraphs should not be used Advisory Decidable Rule
MisraC2025:5.1 External identifiers shall be distinct Required Decidable Rule
MisraC2025:5.2 Identifiers declared in the same scope and name space shall be distinct Required Decidable Rule
MisraC2025:5.3 An identifier declared in an inner scope shall not hide an identifier declared in an outer scope Required Decidable Rule
MisraC2025:5.4 Macro identifiers shall be distinct Required Decidable Rule
MisraC2025:5.5 Identifiers shall be distinct from macro names Required Decidable Rule
MisraC2025:5.6 A typedef name shall be a unique identifier Required Decidable Rule
MisraC2025:5.7 A tag name shall be a unique identifier Required Decidable Rule
MisraC2025:5.8 Identifiers that define objects or functions with external linkage shall be unique Required Decidable Rule
MisraC2025:5.9 Identifiers that define objects or functions with internal linkage should be unique Advisory Decidable Rule
MisraC2025:5.10 A reserved identifier or reserved macro name shall not be declared Required Decidable Rule
MisraC2025:6.1 Bit-fields shall only be declared with an appropriate type Required Decidable Rule
MisraC2025:6.2 Single-bit named bit-fields shall not be of a signed type Required Decidable Rule
MisraC2025:6.3 A bit-field shall not be declared as a member of a union Required Decidable Rule
MisraC2025:7.1 Octal constants shall not be used Required Decidable Rule
MisraC2025:7.2 A "u" or "U" suffix shall be applied to all integer constants that are represented in an unsigned type Required Decidable Rule
MisraC2025:7.3 The lowercase character "l" shall not be used in a literal suffix Required Decidable Rule
MisraC2025:7.4 A string literal shall not be assigned to an object unless the object's type is "pointer to const-qualified char" Required Decidable Rule
MisraC2025:7.5 The argument of an integer constant macro shall have an appropriate form Mandatory Decidable Rule
MisraC2025:7.6 The small integer variants of the minimum-width integer constant macros shall not be used Required Decidable Rule
MisraC2025:8.1 Types shall be explicitly specified Required Decidable Rule
MisraC2025:8.2 Function types shall be in prototype form with named parameters Required Decidable Rule
MisraC2025:8.3 All declarations of an object or function shall use the same names and type qualifiers Required Decidable Rule
MisraC2025:8.4 A compatible declaration shall be visible when an object or function with external linkage is defined Required Decidable Rule
MisraC2025:8.5 An external object or function shall be declared once in one and only one file Required Decidable Rule
MisraC2025:8.6 An identifier with external linkage shall have exactly one external definition Required Decidable Rule
MisraC2025:8.7 Functions and objects should not be defined with external linkage if they are referenced in only one translation unit Advisory Decidable Rule
MisraC2025:8.8 The static storage class specifier shall be used in all declarations of objects and functions that have internal linkage Required Decidable Rule
MisraC2025:8.9 An object should be declared at block scope if its identifier only appears in a single function Advisory Decidable Rule
MisraC2025:8.10 An inline function shall be declared with the static storage class Required Decidable Rule
MisraC2025:8.11 When an array with external linkage is declared, its size should be explicitly specified Advisory Decidable Rule
MisraC2025:8.12 Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique Required Decidable Rule
MisraC2025:8.13 A pointer should point to a const-qualified type whenever possible Advisory Undecidable Rule
MisraC2025:8.14 The restrict type qualifier shall not be used Required Decidable Rule
MisraC2025:8.15 All declarations of an object with an explicit alignment specification shall specify the same alignment Required Decidable Rule
MisraC2025:8.16 The alignment specification of zero should not appear in an object declaration Advisory Decidable Rule
MisraC2025:8.17 At most one explicit alignment specifier should appear in an object declaration Advisory Decidable Rule
MisraC2025:8.18 There shall be no tentative definitions in a header file Required Decidable Rule-
MisraC2025:8.19 There should be no external declarations in a source file Advisory Decidable Rule-
MisraC2025:9.1 The value of an object with automatic storage duration shall not be read before it has been set Mandatory Undecidable Rule
MisraC2025:9.2 The initializer for an aggregate or union shall be enclosed in braces Required Decidable Rule
MisraC2025:9.3 Arrays shall not be partially initialized Required Decidable Rule
MisraC2025:9.4 An element of an object shall not be initialized more than once Required Decidable Rule
MisraC2025:9.5 Where designated initializers are used to initialize an array object the size of the array shall be specified explicitly Required Decidable Rule
MisraC2025:9.6 An initializer using chained designators shall not contain initializers without designators Required Decidable Rule
MisraC2025:9.7 Atomic objects shall be appropriately initialized before being accessed Mandatory Undecidable Rule
MisraC2025:10.1 Operands shall not be of an inappropriate essential type Required Decidable Rule
MisraC2025:10.2 Expressions of essentially character type shall not be used inappropriately in addition and subtraction operations Required Decidable Rule
MisraC2025: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 Required Decidable Rule
MisraC2025:10.4 Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category Required Decidable Rule
MisraC2025:10.5 The value of an expression should not be cast to an inappropriate essential type Advisory Decidable Rule
MisraC2025:10.6 The value of a composite expression shall not be assigned to an object with wider essential type Required Decidable Rule
MisraC2025:10.7 If a composite expression is used as one operand of an operator in which the usual arithmetic conversions are performed then the other operand shall not have wider essential type Required Decidable Rule
MisraC2025:10.8 The value of a composite expression shall not be cast to a different essential type category or a wider essential type Required Decidable Rule
MisraC2025:11.1 Conversions shall not be performed between a pointer to a function and any other type Required Decidable Rule
MisraC2025:11.2 Conversions shall not be performed between a pointer to an incomplete type and any other type Required Decidable Rule
MisraC2025:11.3 A conversion shall not be performed between a pointer to object type and a pointer to a different object type Required Decidable Rule
MisraC2025:11.4 A conversion shall not be performed between a pointer to object and an arithmetic type Required Decidable Rule
MisraC2025:11.5 A conversion should not be performed from pointer to void into pointer to object Advisory Decidable Rule
MisraC2025:11.6 A cast shall not be performed between pointer to void and an arithmetic type Required Decidable Rule
MisraC2025:11.8 A conversion shall not remove any const, volatile or _Atomic qualification from the type pointed to by a pointer Required Decidable Rule
MisraC2025:11.9 The macro NULL shall be the only permitted form of integer null pointer constant Required Decidable Rule
MisraC2025:11.10 The _Atomic qualifier shall not be applied to the incomplete type void Required Decidable Rule
MisraC2025:11.11 Pointers shall not be implicitly compared to NULL Required Decidable Rule-
MisraC2025:12.1 The precedence of operators within expressions should be made explicit Advisory Decidable Rule
MisraC2025:12.2 The right hand operand of a shift operator shall lie in the range zero to one less than the width in bits of the essential type of the left hand operand Required Undecidable Rule
MisraC2025:12.3 The comma operator should not be used Advisory Decidable Rule
MisraC2025:12.4 Evaluation of constant expressions should not lead to unsigned integer wrap-around Advisory Decidable Rule
MisraC2025:12.5 The sizeof operator shall not have an operand which is a function parameter declared as "array of type" Mandatory Decidable Rule
MisraC2025:12.6 Structure and union members of atomic objects shall not be directly accessed Required Decidable Rule
MisraC2025:13.1 Initializer lists shall not contain persistent side effects Required Undecidable Rule
MisraC2025:13.2 The value of an expression and its persistent side effects shall be the same under all permitted evaluation orders and shall be independent from thread interleaving Required Undecidable Rule
MisraC2025:13.3 A full expression containing an increment (++) or decrement (--) operator should have no other potential side effects other than that caused by the increment or decrement operator Advisory Decidable Rule
MisraC2025:13.4 The result of an assignment operator should not be used Advisory Decidable Rule
MisraC2025:13.5 The right hand operand of a logical && or || operator shall not contain persistent side effects Required Undecidable Rule
MisraC2025:13.6 The operand of the sizeof operator shall not contain any expression which has potential side effects Required Decidable Rule
MisraC2025:14.1 A loop counter shall not have essentially floating type Required Undecidable Rule
MisraC2025:14.2 A for loop shall be well-formed Required Undecidable Rule
MisraC2025:14.3 Controlling expressions shall not be invariant Required Undecidable Rule
MisraC2025:14.4 The controlling expression of an if statement and the controlling expression of an iteration-statement shall have essentially Boolean type Required Decidable Rule
MisraC2025:15.1 The goto statement should not be used Advisory Decidable Rule
MisraC2025:15.2 The goto statement shall jump to a label declared later in the same function Required Decidable Rule
MisraC2025:15.3 Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement Required Decidable Rule
MisraC2025:15.4 There should be no more than one break or goto statement used to terminate any iteration statement Advisory Decidable Rule
MisraC2025:15.5 A function should have a single point of exit at the end Disapplied Decidable Rule
MisraC2025:15.6 The body of an iteration-statement or a selection-statement shall be a compound-statement Required Decidable Rule
MisraC2025:15.7 All if ... else if constructs shall be terminated with an else statement Required Decidable Rule
MisraC2025:16.1 All switch statements shall be well-formed Required Decidable Rule
MisraC2025:16.2 A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement Required Decidable Rule
MisraC2025:16.3 Every switch-clause shall be appropriately terminated Required Decidable Rule
MisraC2025:16.4 Every switch statement shall have a default label Required Decidable Rule
MisraC2025:16.5 A default label shall appear as either the first or the last switch label of a switch statement Required Decidable Rule
MisraC2025:16.6 Every switch statement shall have at least two switch-clauses Required Decidable Rule
MisraC2025:16.7 A switch-expression shall not have essentially Boolean type Required Decidable Rule
MisraC2025:17.1 The standard header file <stdarg.h> shall not be used Required Decidable Rule
MisraC2025:17.2 Functions shall not call themselves, either directly or indirectly Required Undecidable Rule
MisraC2025:17.3 A function shall not be declared implicitly Mandatory Decidable Rule
MisraC2025:17.4 All exit paths from a function with non-void return type shall have an explicit return statement with an expression Mandatory Decidable Rule
MisraC2025:17.5 The function argument corresponding to a parameter declared to have an array type shall have an appropriate number of elements Required Undecidable Rule
MisraC2025:17.7 The value returned by a function having non-void return type shall be used Required Decidable Rule
MisraC2025:17.8 A function parameter should not be modified Advisory Undecidable Rule
MisraC2025:17.9 A function declared with a _Noreturn function specifier shall not return to its caller Mandatory Undecidable Rule
MisraC2025:17.10 A function declared with a _Noreturn function specifier shall have void return type Required Decidable Rule
MisraC2025:17.11 A function that never returns should be declared with a _Noreturn function specifier Advisory Undecidable Rule
MisraC2025:17.12 A function identifier should only be used with either a preceding &, or with a parenthesized parameter list Advisory Decidable Rule
MisraC2025:17.13 A function type shall not be type qualified Required Decidable Rule
MisraC2025:18.1 A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand Required Undecidable Rule
MisraC2025:18.2 Subtraction between pointers shall only be applied to pointers that address elements of the same array Required Undecidable Rule
MisraC2025:18.3 The relational operators >, >=, < and <= shall not be applied to expressions of pointer type except where they point into the same object Required Undecidable Rule
MisraC2025:18.4 The +, -, += and -= operators should not be applied to an expression of pointer type Advisory Decidable Rule
MisraC2025:18.5 Declarations should contain no more than two levels of pointer nesting Advisory Decidable Rule
MisraC2025:18.6 The address of an object with automatic or thread-local storage shall not be copied to another object that persists after the first object has ceased to exist Required Undecidable Rule
MisraC2025:18.7 Flexible array members shall not be declared Required Decidable Rule
MisraC2025:18.8 Variable-length arrays shall not be used Required Decidable Rule
MisraC2025:18.9 An object with temporary lifetime shall not undergo array-to-pointer conversion Required Decidable Rule
MisraC2025:18.10 Pointers to variably-modified array types shall not be used Mandatory Decidable Rule
MisraC2025:19.1 An object shall not be assigned or copied to an overlapping object Mandatory Undecidable Rule
MisraC2025:19.2 The union keyword should not be used Advisory Decidable Rule
MisraC2025:19.3 A union member shall not be read unless it has been previously set Required Undecidable Rule-
MisraC2025:20.1 #include directives should only be preceded by preprocessor directives or comments Advisory Decidable Rule
MisraC2025:20.2 The ', " or \ characters and the /* or // character sequences shall not occur in a header file name Required Decidable Rule
MisraC2025:20.3 The #include directive shall be followed by either a <filename> or "filename" sequence Required Decidable Rule
MisraC2025:20.4 A macro shall not be defined with the same name as a keyword Required Decidable Rule
MisraC2025:20.5 #undef should not be used Advisory Decidable Rule
MisraC2025:20.6 Tokens that look like a preprocessing directive shall not occur within a macro argument Required Decidable Rule
MisraC2025:20.7 Expressions resulting from the expansion of macro parameters shall be appropriately delimited Required Decidable Rule
MisraC2025:20.8 The controlling expression of a #if or #elif preprocessing directive shall evaluate to 0 or 1 Required Decidable Rule
MisraC2025:20.9 All identifiers used in the controlling expression of #if or #elif preprocessing directives shall be #define'd before evaluation Required Decidable Rule
MisraC2025:20.10 The # and ## preprocessor operators should not be used Advisory Decidable Rule
MisraC2025:20.11 A macro parameter immediately following a # operator shall not immediately be followed by a ## operator Required Decidable Rule
MisraC2025: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 Required Decidable Rule
MisraC2025:20.13 A line whose first token is # shall be a valid preprocessing directive Required Decidable Rule
MisraC2025:20.14 All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if, #ifdef or #ifndef directive to which they are related Required Decidable Rule
MisraC2025:20.15 #define and #undef shall not be used on a reserved identifier or reserved macro name Required Decidable Rule
MisraC2025:21.3 The memory allocation and deallocation functions of <stdlib.h> shall not be used Required Decidable Rule
MisraC2025:21.4 The standard header file <setjmp.h> shall not be used Required Decidable Rule
MisraC2025:21.5 The standard header file <signal.h> shall not be used Required Decidable Rule
MisraC2025:21.6 The Standard Library input/output functions shall not be used Required Decidable Rule
MisraC2025:21.7 The Standard Library functions atof, atoi, atol and atoll of <stdlib.h> shall not be used Required Decidable Rule
MisraC2025:21.8 The Standard Library termination functions of <stdlib.h> shall not be used Required Decidable Rule
MisraC2025:21.9 The Standard Library functions bsearch and qsort of <stdlib.h> shall not be used Required Decidable Rule
MisraC2025:21.10 The Standard Library time and date functions shall not be used Required Decidable Rule
MisraC2025:21.11 The standard header file <tgmath.h> should not be used Advisory Decidable Rule
MisraC2025:21.12 The standard header file <fenv.h> shall not be used Required Decidable Rule
MisraC2025:21.13 Any value passed to a function in <ctype.h> shall be representable as an unsigned char or be the value EOF Mandatory Undecidable Rule
MisraC2025:21.14 The Standard Library function memcmp shall not be used to compare null terminated strings Required Undecidable Rule
MisraC2025:21.15 The pointer arguments to the Standard Library functions memcpy, memmove and memcmp shall be pointers to qualified or unqualified versions of compatible types Required Decidable Rule
MisraC2025:21.16 The pointer arguments to the Standard Library function memcmp shall point to either a pointer type, an essentially signed type, an essentially unsigned type, an essentially Boolean type or an essentially enum type Required Decidable Rule
MisraC2025:21.17 Use of the string handling functions from <string.h> shall not result in accesses beyond the bounds of the objects referenced by their pointer parameters Mandatory Undecidable Rule
MisraC2025:21.18 The size_t argument passed to any function in <string.h> shall have an appropriate value Mandatory Undecidable Rule
MisraC2025:21.19 The pointers returned by the Standard Library functions localeconv, getenv, setlocale or strerror shall only be used as if they have pointer to const-qualified type Mandatory Undecidable Rule
MisraC2025:21.20 The pointer returned by the Standard Library functions asctime, ctime, gmtime, localtime, localeconv, getenv, setlocale or strerror shall not be used following a subsequent call to the same function Mandatory Undecidable Rule
MisraC2025:21.21 The Standard Library function system of <stdlib.h> shall not be used Required Decidable Rule
MisraC2025:21.22 All operand arguments to any type-generic macros declared in <tgmath.h> shall have an appropriate essential type Mandatory Decidable Rule
MisraC2025:21.23 All operand arguments to any multi-argument type-generic macros declared in <tgmath.h> shall have the same standard type Required Decidable Rule
MisraC2025:21.24 The random number generator functions of <stdlib.h> shall not be used Required Decidable Rule
MisraC2025:21.25 All memory synchronization operations shall be executed in sequentially consistent order Required Decidable Rule
MisraC2025:21.26 The Standard Library function mtx_timedlock() shall only be invoked on mutex objects of appropriate mutex type Required Undecidable Rule-
MisraC2025:22.1 All resources obtained dynamically by means of Standard Library functions shall be explicitly released Required Undecidable Rule
MisraC2025:22.2 A block of memory shall only be freed if it was allocated by means of a Standard Library function Mandatory Undecidable Rule
MisraC2025:22.3 The same file shall not be open for read and write access at the same time on different streams Required Undecidable Rule
MisraC2025:22.4 There shall be no attempt to write to a stream which has been opened as read-only Mandatory Undecidable Rule
MisraC2025:22.5 A pointer to a FILE object shall not be dereferenced Mandatory Undecidable Rule
MisraC2025:22.6 The value of a pointer to a FILE shall not be used after the associated stream has been closed Mandatory Undecidable Rule
MisraC2025:22.7 The macro EOF shall only be compared with the unmodified return value from any Standard Library function capable of returning EOF Required Undecidable Rule
MisraC2025:22.8 The value of errno shall be set to zero prior to a call to an errno-setting-function Required Undecidable Rule
MisraC2025:22.9 The value of errno shall be tested against zero after calling an errno-setting-function Required Undecidable Rule
MisraC2025:22.10 The value of errno shall only be tested when the last function to be called was an errno-setting-function Required Undecidable Rule
MisraC2025:22.11 A thread that was previously either joined or detached shall not be subsequently joined nor detached Required Undecidable Rule
MisraC2025:22.12 Thread objects, thread synchronization objects, and thread-specific storage pointers shall only be accessed by the appropriate Standard Library functions Mandatory Undecidable Rule
MisraC2025:22.13 Thread objects, thread synchronization objects and thread-specific storage pointers shall have appropriate storage duration Required Decidable Rule
MisraC2025:22.14 Thread synchronization objects shall be initialized before being accessed Mandatory Undecidable Rule-
MisraC2025:22.15 Thread synchronization objects and thread-specific storage pointers shall not be destroyed until after all threads accessing them have terminated Required Undecidable Rule-
MisraC2025:22.16 All mutex objects locked by a thread shall be explicitly unlocked by the same thread Required Undecidable Rule
MisraC2025:22.17 No thread shall unlock a mutex or call cnd_wait() or cnd_timedwait() for a mutex it has not locked before Required Undecidable Rule
MisraC2025:22.18 Non-recursive mutexes shall not be recursively locked Required Undecidable Rule
MisraC2025:22.19 A condition variable shall be associated with at most one mutex object Required Undecidable Rule-
MisraC2025:22.20 Thread-specific storage pointers shall be created before being accessed Mandatory Undecidable Rule-
MisraC2025:23.1 A generic selection should only be expanded from a macro Advisory Decidable Rule
MisraC2025:23.2 A generic selection that is not expanded from a macro shall not contain potential side effects in the controlling expression Required Decidable Rule
MisraC2025:23.3 A generic selection should contain at least one non-default association Advisory Decidable Rule
MisraC2025:23.4 A generic association shall list an appropriate type Required Decidable Rule
MisraC2025:23.5 A generic selection should not depend on implicit pointer type conversion Advisory Decidable Rule
MisraC2025:23.6 The controlling expression of a generic selection shall have an essential type that matches its standard type Required Decidable Rule
MisraC2025:23.7 A generic selection that is expanded from a macro should evaluate its argument only once Advisory Decidable Rule
MisraC2025:23.8 A default association shall appear as either the first or the last association of a generic selection Required Decidable Rule
MisraC2025:D.1.1 Any implementation-defined behaviour on which the output of the program depends shall be documented and understood Required Undecidable Directive-
MisraC2025:D.1.2 The use of language extensions should be minimized Advisory Undecidable Directive
MisraC2025:D.2.1 All source files shall compile without any compilation errors Required Undecidable Directive
MisraC2025:D.3.1 All code shall be traceable to documented requirements Required Undecidable Directive-
MisraC2025:D.4.1 Run-time failures shall be minimized Required Undecidable Directive
MisraC2025:D.4.2 All usage of assembly language should be documented Advisory Undecidable Directive-
MisraC2025:D.4.3 Assembly language shall be encapsulated and isolated Required Undecidable Directive
MisraC2025:D.4.4 Sections of code should not be "commented out" Advisory Undecidable Directive
MisraC2025:D.4.5 Identifiers in the same name space with overlapping visibility should be typographically unambiguous Advisory Undecidable Directive
MisraC2025:D.4.6 typedefs that indicate size and signedness should be used in place of the basic integer types Advisory Undecidable Directive
MisraC2025:D.4.7 If a function returns error information, then that error information shall be tested Required Undecidable Directive
MisraC2025:D.4.8 If a pointer to a structure or union is never dereferenced within a translation unit, then the implementation of the object should be hidden Advisory Undecidable Directive-
MisraC2025:D.4.9 A function should be used in preference to a function-like macro where they are interchangeable Advisory Undecidable Directive
MisraC2025:D.4.10 Precautions shall be taken in order to prevent the contents of a header file being included more than once Required Undecidable Directive
MisraC2025:D.4.11 The validity of values passed to library functions shall be checked Required Undecidable Directive
MisraC2025:D.4.12 Dynamic memory allocation shall not be used Required Undecidable Directive
MisraC2025:D.4.13 Functions which are designed to provide operations on a resource should be called in an appropriate sequence Advisory Undecidable Directive
MisraC2025:D.4.14 The validity of values received from external sources shall be checked Required Undecidable Directive
MisraC2025:D.4.15 Evaluation of floating-point expressions shall not lead to the undetected generation of infinities and NaNs Required Undecidable Directive
MisraC2025:D.5.1 There shall be no data races between threads Required Undecidable Directive
MisraC2025:D.5.2 There shall be no deadlocks between threads Required Undecidable Directive
MisraC2025:D.5.3 There shall be no dynamic thread creation Required Undecidable Directive

MISRA C:2023

The following table shows the CodeSonar warning classes that are associated with the guidelines in MISRA C:2023.

This table is also available in CSV format: MisraC2023-mapping.csv.

MisraC2023 Category Decidability Guideline TypeC Warning Classes
MisraC2023:1.1 The program shall contain no violations of the standard C syntax and constraints, and shall not exceed the implementation's translation limits Required Decidable Rule
MisraC2023:1.2 Language extensions should not be used Advisory Undecidable Rule
MisraC2023:1.3 There shall be no occurrence of undefined or critical unspecified behaviour Required Undecidable Rule
MisraC2023:1.4 Emergent language features shall not be used Required Decidable Rule
MisraC2023:1.5 Obsolescent language features shall not be used Required Undecidable Rule
MisraC2023:2.1 A project shall not contain unreachable code Required Undecidable Rule
MisraC2023:2.2 A project shall not contain dead code Required Undecidable Rule
MisraC2023:2.3 A project should not contain unused type declarations Advisory Decidable Rule
MisraC2023:2.4 A project should not contain unused tag declarations Advisory Decidable Rule
MisraC2023:2.5 A project should not contain unused macro definitions Advisory Decidable Rule
MisraC2023:2.6 A function should not contain unused label declarations Advisory Decidable Rule
MisraC2023:2.7 A function should not contain unused parameters Advisory Decidable Rule
MisraC2023:2.8 A project should not contain unused object definitions Advisory Decidable Rule
MisraC2023:3.1 The character sequences /* and // shall not be used within a comment Required Decidable Rule
MisraC2023:3.2 Line-splicing shall not be used in // comments Required Decidable Rule
MisraC2023:4.1 Octal and hexadecimal escape sequences shall be terminated Required Decidable Rule
MisraC2023:4.2 Trigraphs should not be used Advisory Decidable Rule
MisraC2023:5.1 External identifiers shall be distinct Required Decidable Rule
MisraC2023:5.2 Identifiers declared in the same scope and name space shall be distinct Required Decidable Rule
MisraC2023:5.3 An identifier declared in an inner scope shall not hide an identifier declared in an outer scope Required Decidable Rule
MisraC2023:5.4 Macro identifiers shall be distinct Required Decidable Rule
MisraC2023:5.5 Identifiers shall be distinct from macro names Required Decidable Rule
MisraC2023:5.6 A typedef name shall be a unique identifier Required Decidable Rule
MisraC2023:5.7 A tag name shall be a unique identifier Required Decidable Rule
MisraC2023:5.8 Identifiers that define objects or functions with external linkage shall be unique Required Decidable Rule
MisraC2023:5.9 Identifiers that define objects or functions with internal linkage should be unique Advisory Decidable Rule
MisraC2023:6.1 Bit-fields shall only be declared with an appropriate type Required Decidable Rule
MisraC2023:6.2 Single-bit named bit-fields shall not be of a signed type Required Decidable Rule
MisraC2023:6.3 A bit field shall not be declared as a member of a union Required Decidable Rule
MisraC2023:7.1 Octal constants shall not be used Required Decidable Rule
MisraC2023:7.2 A "u" or "U" suffix shall be applied to all integer constants that are represented in an unsigned type Required Decidable Rule
MisraC2023:7.3 The lowercase character "l" shall not be used in a literal suffix Required Decidable Rule
MisraC2023:7.4 A string literal shall not be assigned to an object unless the object's type is "pointer to const-qualified char" Required Decidable Rule
MisraC2023:7.5 The argument of an integer constant macro shall have an appropriate form Mandatory Decidable Rule
MisraC2023:7.6 The small integer variants of the minimum-width integer constant macros shall not be used Required Decidable Rule
MisraC2023:8.1 Types shall be explicitly specified Required Decidable Rule
MisraC2023:8.2 Function types shall be in prototype form with named parameters Required Decidable Rule
MisraC2023:8.3 All declarations of an object or function shall use the same names and type qualifiers Required Decidable Rule
MisraC2023:8.4 A compatible declaration shall be visible when an object or function with external linkage is defined Required Decidable Rule
MisraC2023:8.5 An external object or function shall be declared once in one and only one file Required Decidable Rule
MisraC2023:8.6 An identifier with external linkage shall have exactly one external definition Required Decidable Rule
MisraC2023:8.7 Functions and objects should not be defined with external linkage if they are referenced in only one translation unit Advisory Decidable Rule
MisraC2023:8.8 The static storage class specifier shall be used in all declarations of objects and functions that have internal linkage Required Decidable Rule
MisraC2023:8.9 An object should be declared at block scope if its identifier only appears in a single function Advisory Decidable Rule
MisraC2023:8.10 An inline function shall be declared with the static storage class Required Decidable Rule
MisraC2023:8.11 When an array with external linkage is declared, its size should be explicitly specified Advisory Decidable Rule
MisraC2023:8.12 Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique Required Decidable Rule
MisraC2023:8.13 A pointer should point to a const-qualified type whenever possible Advisory Undecidable Rule
MisraC2023:8.14 The restrict type qualifier shall not be used Required Decidable Rule
MisraC2023:8.15 All declarations of an object with an explicit alignment specification shall specify the same alignment Required Decidable Rule
MisraC2023:8.16 The alignment specification of zero should not appear in an object declaration Advisory Decidable Rule
MisraC2023:8.17 At most one explicit alignment specifier should appear in an object declaration Advisory Decidable Rule
MisraC2023:9.1 The value of an object with automatic storage duration shall not be read before it has been set Mandatory Undecidable Rule
MisraC2023:9.2 The initializer for an aggregate or union shall be enclosed in braces Required Decidable Rule
MisraC2023:9.3 Arrays shall not be partially initialized Required Decidable Rule
MisraC2023:9.4 An element of an object shall not be initialized more than once Required Decidable Rule
MisraC2023:9.5 Where designated initializers are used to initialize an array object the size of the array shall be specified explicitly Required Decidable Rule
MisraC2023:9.6 An initializer using chained designators shall not contain initializers without designators Required Decidable Rule
MisraC2023:9.7 Atomic objects shall be appropriately initialized before being accessed Mandatory Undecidable Rule
MisraC2023:10.1 Operands shall not be of an inappropriate essential type Required Decidable Rule
MisraC2023:10.2 Expressions of essentially character type shall not be used inappropriately in addition and subtraction operations Required Decidable Rule
MisraC2023: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 Required Decidable Rule
MisraC2023:10.4 Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category Required Decidable Rule
MisraC2023:10.5 The value of an expression should not be cast to an inappropriate essential type Advisory Decidable Rule
MisraC2023:10.6 The value of a composite expression shall not be assigned to an object with wider essential type Required Decidable Rule
MisraC2023:10.7 If a composite expression is used as one operand of an operator in which the usual arithmetic conversions are performed then the other operand shall not have wider essential type Required Decidable Rule
MisraC2023:10.8 The value of a composite expression shall not be cast to a different essential type category or a wider essential type Required Decidable Rule
MisraC2023:11.1 Conversions shall not be performed between a pointer to a function and any other type Required Decidable Rule
MisraC2023:11.2 Conversions shall not be performed between a pointer to an incomplete type and any other type Required Decidable Rule
MisraC2023:11.3 A conversion shall not be performed between a pointer to object type and a pointer to a different object type Required Decidable Rule
MisraC2023:11.4 A conversion should not be performed between a pointer to object and an integer type Advisory Decidable Rule
MisraC2023:11.5 A conversion should not be performed from pointer to void into pointer to object Advisory Decidable Rule
MisraC2023:11.6 A cast shall not be performed between pointer to void and an arithmetic type Required Decidable Rule
MisraC2023:11.7 A cast shall not be performed between pointer to object and a non-integer arithmetic type Required Decidable Rule
MisraC2023:11.8 A conversion shall not remove any const, volatile or _Atomic qualification from the type pointed to by a pointer Required Decidable Rule
MisraC2023:11.9 The macro NULL shall be the only permitted form of integer null pointer constant Required Decidable Rule
MisraC2023:11.10 The _Atomic qualifier shall not be applied to the incomplete type void Required Decidable Rule
MisraC2023:12.1 The precedence of operators within expressions should be made explicit Advisory Decidable Rule
MisraC2023:12.2 The right hand operand of a shift operator shall lie in the range zero to one less than the width in bits of the essential type of the left hand operand Required Undecidable Rule
MisraC2023:12.3 The comma operator should not be used Advisory Decidable Rule
MisraC2023:12.4 Evaluation of constant expressions should not lead to unsigned integer wrap-around Advisory Decidable Rule
MisraC2023:12.5 The sizeof operator shall not have an operand which is a function parameter declared as "array of type" Mandatory Decidable Rule
MisraC2023:12.6 Structure and union members of atomic objects shall not be directly accessed Required Decidable Rule
MisraC2023:13.1 Initializer lists shall not contain persistent side effects Required Undecidable Rule
MisraC2023:13.2 The value of an expression and its persistent side effects shall be the same under all permitted evaluation orders and shall be independent from thread interleaving Required Undecidable Rule
MisraC2023:13.3 A full expression containing an increment (++) or decrement (--) operator should have no other potential side effects other than that caused by the increment or decrement operator Advisory Decidable Rule
MisraC2023:13.4 The result of an assignment operator should not be used Advisory Decidable Rule
MisraC2023:13.5 The right hand operand of a logical && or || operator shall not contain persistent side effects Required Undecidable Rule
MisraC2023:13.6 The operand of the sizeof operator shall not contain any expression which has potential side effects Required Decidable Rule
MisraC2023:14.1 A loop counter shall not have essentially floating type Required Undecidable Rule
MisraC2023:14.2 A for loop shall be well-formed Required Undecidable Rule
MisraC2023:14.3 Controlling expressions shall not be invariant Required Undecidable Rule
MisraC2023:14.4 The controlling expression of an if statement and the controlling expression of an iteration-statement shall have essentially Boolean type Required Decidable Rule
MisraC2023:15.1 The goto statement should not be used Advisory Decidable Rule
MisraC2023:15.2 The goto statement shall jump to a label declared later in the same function Required Decidable Rule
MisraC2023:15.3 Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement Required Decidable Rule
MisraC2023:15.4 There should be no more than one break or goto statement used to terminate any iteration statement Advisory Decidable Rule
MisraC2023:15.5 A function should have a single point of exit at the end Advisory Decidable Rule
MisraC2023:15.6 The body of an iteration-statement or a selection-statement shall be a compound-statement Required Decidable Rule
MisraC2023:15.7 All if ... else if constructs shall be terminated with an else statement Required Decidable Rule
MisraC2023:16.1 All switch statements shall be well-formed Required Decidable Rule
MisraC2023:16.2 A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement Required Decidable Rule
MisraC2023:16.3 An unconditional break statement shall terminate every switch-clause Required Decidable Rule
MisraC2023:16.4 Every switch statement shall have a default label Required Decidable Rule
MisraC2023:16.5 A default label shall appear as either the first or the last switch label of a switch statement Required Decidable Rule
MisraC2023:16.6 Every switch statement shall have at least two switch-clauses Required Decidable Rule
MisraC2023:16.7 A switch-expression shall not have essentially Boolean type Required Decidable Rule
MisraC2023:17.1 The standard header file <stdarg.h> shall not be used Required Decidable Rule
MisraC2023:17.2 Functions shall not call themselves, either directly or indirectly Required Undecidable Rule
MisraC2023:17.3 A function shall not be declared implicitly Mandatory Decidable Rule
MisraC2023:17.4 All exit paths from a function with non-void return type shall have an explicit return statement with an expression Mandatory Decidable Rule
MisraC2023:17.5 The function argument corresponding to a parameter declared to have an array type shall have an appropriate number of elements Required Undecidable Rule
MisraC2023:17.6 The declaration of an array parameter shall not contain the static keyword between the [ ] Mandatory Decidable Rule
MisraC2023:17.7 The value returned by a function having non-void return type shall be used Required Decidable Rule
MisraC2023:17.8 A function parameter should not be modified Advisory Undecidable Rule
MisraC2023:17.9 A function declared with a _Noreturn function specifier shall not return to its caller Mandatory Undecidable Rule
MisraC2023:17.10 A function declared with a _Noreturn function specifier shall have void return type Required Decidable Rule
MisraC2023:17.11 A function that never returns should be declared with a _Noreturn function specifier Advisory Undecidable Rule
MisraC2023:17.12 A function identifier should only be used with either a preceding &, or with a parenthesized parameter list Advisory Decidable Rule
MisraC2023:17.13 A function type shall not be type qualified Required Decidable Rule
MisraC2023:18.1 A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand Required Undecidable Rule
MisraC2023:18.2 Subtraction between pointers shall only be applied to pointers that address elements of the same array Required Undecidable Rule
MisraC2023:18.3 The relational operators >, >=, < and <= shall not be applied to expressions of pointer type except where they point into the same object Required Undecidable Rule
MisraC2023:18.4 The +, -, += and -= operators should not be applied to an expression of pointer type Advisory Decidable Rule
MisraC2023:18.5 Declarations should contain no more than two levels of pointer nesting Advisory Decidable Rule
MisraC2023:18.6 The address of an object with automatic or thread-local storage shall not be copied to another object that persists after the first object has ceased to exist Required Undecidable Rule
MisraC2023:18.7 Flexible array members shall not be declared Required Decidable Rule
MisraC2023:18.8 Variable-length arrays shall not be used Required Decidable Rule
MisraC2023:18.9 An object with temporary lifetime shall not undergo array-to-pointer conversion Required Decidable Rule
MisraC2023:18.10 Pointers to variably-modified array types shall not be used Mandatory Decidable Rule
MisraC2023:19.1 An object shall not be assigned or copied to an overlapping object Mandatory Undecidable Rule
MisraC2023:19.2 The union keyword should not be used Advisory Decidable Rule
MisraC2023:20.1 #include directives should only be preceded by preprocessor directives or comments Advisory Decidable Rule
MisraC2023:20.2 The ', " or \ characters and the /* or // character sequences shall not occur in a header file name Required Decidable Rule
MisraC2023:20.3 The #include directive shall be followed by either a <filename> or "filename" sequence Required Decidable Rule
MisraC2023:20.4 A macro shall not be defined with the same name as a keyword Required Decidable Rule
MisraC2023:20.5 #undef should not be used Advisory Decidable Rule
MisraC2023:20.6 Tokens that look like a preprocessing directive shall not occur within a macro argument Required Decidable Rule
MisraC2023:20.7 Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses Required Decidable Rule
MisraC2023:20.8 The controlling expression of a #if or #elif preprocessing directive shall evaluate to 0 or 1 Required Decidable Rule
MisraC2023:20.9 All identifiers used in the controlling expression of #if or #elif preprocessing directives shall be #define'd before evaluation Required Decidable Rule
MisraC2023:20.10 The # and ## preprocessor operators should not be used Advisory Decidable Rule
MisraC2023:20.11 A macro parameter immediately following a # operator shall not immediately be followed by a ## operator Required Decidable Rule
MisraC2023: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 Required Decidable Rule
MisraC2023:20.13 A line whose first token is # shall be a valid preprocessing directive Required Decidable Rule
MisraC2023:20.14 All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if, #ifdef or #ifndef directive to which they are related Required Decidable Rule
MisraC2023:21.1 #define and #undef shall not be used on a reserved identifier or reserved macro name Required Decidable Rule
MisraC2023:21.2 A reserved identifier or reserved macro name shall not be declared Required Decidable Rule
MisraC2023:21.3 The memory allocation and deallocation functions of <stdlib.h> shall not be used Required Decidable Rule
MisraC2023:21.4 The standard header file <setjmp.h> shall not be used Required Decidable Rule
MisraC2023:21.5 The standard header file <signal.h> shall not be used Required Decidable Rule
MisraC2023:21.6 The Standard Library input/output functions shall not be used Required Decidable Rule
MisraC2023:21.7 The atof, atoi, atol and atoll functions of <stdlib.h> shall not be used Required Decidable Rule
MisraC2023:21.8 The Standard Library termination functions of <stdlib.h> shall not be used Required Decidable Rule
MisraC2023:21.9 The library functions bsearch and qsort of <stdlib.h> shall not be used Required Decidable Rule
MisraC2023:21.10 The Standard Library time and date functions shall not be used Required Decidable Rule
MisraC2023:21.11 The standard header file <tgmath.h> should not be used Advisory Decidable Rule
MisraC2023:21.12 The standard header file <fenv.h> shall not be used Required Decidable Rule
MisraC2023:21.13 Any value passed to a function in <ctype.h> shall be representable as an unsigned char or be the value EOF Mandatory Undecidable Rule
MisraC2023:21.14 The Standard Library function memcmp shall not be used to compare null terminated strings Required Undecidable Rule
MisraC2023:21.15 The pointer arguments to the Standard Library functions memcpy, memmove and memcmp shall be pointers to qualified or unqualified versions of compatible types Required Decidable Rule
MisraC2023:21.16 The pointer arguments to the Standard Library function memcmp shall point to either a pointer type, an essentially signed type, an essentially unsigned type, an essentially Boolean type or an essentially enum type Required Decidable Rule
MisraC2023:21.17 Use of the string handling functions from <string.h> shall not result in accesses beyond the bounds of the objects referenced by their pointer parameters Mandatory Undecidable Rule
MisraC2023:21.18 The size_t argument passed to any function in <string.h> shall have an appropriate value Mandatory Undecidable Rule
MisraC2023:21.19 The pointers returned by the Standard Library functions localeconv, getenv, setlocale or, strerror shall only be used as if they have pointer to const-qualified type Mandatory Undecidable Rule
MisraC2023:21.20 The pointer returned by the Standard Library functions asctime, ctime, gmtime, localtime, localeconv, getenv, setlocale or strerror shall not be used following a subsequent call to the same function Mandatory Undecidable Rule
MisraC2023:21.21 The Standard Library function system of <stdlib.h> shall not be used Required Decidable Rule
MisraC2023:21.22 All operand arguments to any type-generic macros declared in <tgmath.h> shall have an appropriate essential type Mandatory Decidable Rule
MisraC2023:21.23 All operand arguments to any multi-argument type-generic macros declared in <tgmath.h> shall have the same standard type Required Decidable Rule
MisraC2023:21.24 The random number generator functions of <stdlib.h> shall not be used Required Decidable Rule
MisraC2023:21.25 All memory synchronization operations shall be executed in sequentially consistent order Required Decidable Rule
MisraC2023:21.26 The Standard Library function mtx_timedlock() shall only be invoked on mutex objects of appropriate mutex type Required Undecidable Rule-
MisraC2023:22.1 All resources obtained dynamically by means of Standard Library functions shall be explicitly released Required Undecidable Rule
MisraC2023:22.2 A block of memory shall only be freed if it was allocated by means of a Standard Library function Mandatory Undecidable Rule
MisraC2023:22.3 The same file shall not be open for read and write access at the same time on different streams Required Undecidable Rule
MisraC2023:22.4 There shall be no attempt to write to a stream which has been opened as read-only Mandatory Undecidable Rule
MisraC2023:22.5 A pointer to a FILE object shall not be dereferenced Mandatory Undecidable Rule
MisraC2023:22.6 The value of a pointer to a FILE shall not be used after the associated stream has been closed Mandatory Undecidable Rule
MisraC2023:22.7 The macro EOF shall only be compared with the unmodified return value from any Standard Library function capable of returning EOF Required Undecidable Rule
MisraC2023:22.8 The value of errno shall be set to zero prior to a call to an errno-setting-function Required Undecidable Rule
MisraC2023:22.9 The value of errno shall be tested against zero after calling an errno-setting-function Required Undecidable Rule
MisraC2023:22.10 The value of errno shall only be tested when the last function to be called was an errno-setting-function Required Undecidable Rule
MisraC2023:22.11 A thread that was previously either joined or detached shall not be subsequently joined nor detached Required Undecidable Rule
MisraC2023:22.12 Thread objects, thread synchronization objects, and thread-specific storage pointers shall only be accessed by the appropriate Standard Library functions Mandatory Undecidable Rule
MisraC2023:22.13 Thread objects, thread synchronization objects and thread-specific storage pointers shall have appropriate storage duration Required Decidable Rule
MisraC2023:22.14 Thread synchronization objects shall be initialized before being accessed Mandatory Undecidable Rule-
MisraC2023:22.15 Thread synchronization objects and thread-specific storage pointers shall not be destroyed until after all threads accessing them have terminated Required Undecidable Rule-
MisraC2023:22.16 All mutex objects locked by a thread shall be explicitly unlocked by the same thread Required Undecidable Rule
MisraC2023:22.17 No thread shall unlock a mutex or call cnd_wait() or cnd_timedwait() for a mutex it has not locked before Required Undecidable Rule
MisraC2023:22.18 Non-recursive mutexes shall not be recursively locked Required Undecidable Rule
MisraC2023:22.19 A condition variable shall be associated with at most one mutex object Required Undecidable Rule-
MisraC2023:22.20 Thread-specific storage pointers shall be created before being accessed Mandatory Undecidable Rule-
MisraC2023:23.1 A generic selection should only be expanded from a macro Advisory Decidable Rule
MisraC2023:23.2 A generic selection that is not expanded from a macro shall not contain potential side effects in the controlling expression Required Decidable Rule
MisraC2023:23.3 A generic selection should contain at least one non-default association Advisory Decidable Rule
MisraC2023:23.4 A generic association shall list an appropriate type Required Decidable Rule
MisraC2023:23.5 A generic selection should not depend on implicit pointer type conversion Advisory Decidable Rule
MisraC2023:23.6 The controlling expression of a generic selection shall have an essential type that matches its standard type Required Decidable Rule
MisraC2023:23.7 A generic selection that is expanded from a macro should evaluate its argument only once Advisory Decidable Rule
MisraC2023:23.8 A default association shall appear as either the first or the last association of a generic selection Required Decidable Rule
MisraC2023:D.1.1 Any implementation-defined behaviour on which the output of the program depends shall be documented and understood Required Undecidable Directive-
MisraC2023:D.2.1 All source files shall compile without any compilation errors Required Undecidable Directive
MisraC2023:D.3.1 All code shall be traceable to documented requirements Required Undecidable Directive-
MisraC2023:D.4.1 Run-time failures shall be minimized Required Undecidable Directive
MisraC2023:D.4.2 All usage of assembly language should be documented Advisory Undecidable Directive-
MisraC2023:D.4.3 Assembly language shall be encapsulated and isolated Required Undecidable Directive
MisraC2023:D.4.4 Sections of code should not be "commented out" Advisory Undecidable Directive
MisraC2023:D.4.5 Identifiers in the same name space with overlapping visibility should be typographically unambiguous Advisory Undecidable Directive
MisraC2023:D.4.6 typedefs that indicate size and signedness should be used in place of the basic numerical types Advisory Undecidable Directive
MisraC2023:D.4.7 If a function returns error information, then that error information shall be tested Required Undecidable Directive
MisraC2023:D.4.8 If a pointer to a structure or union is never dereferenced within a translation unit, then the implementation of the object should be hidden Advisory Undecidable Directive-
MisraC2023:D.4.9 A function should be used in preference to a function-like macro where they are interchangeable Advisory Undecidable Directive
MisraC2023:D.4.10 Precautions shall be taken in order to prevent the contents of a header file being included more than once Required Undecidable Directive
MisraC2023:D.4.11 The validity of values passed to library functions shall be checked Required Undecidable Directive
MisraC2023:D.4.12 Dynamic memory allocation shall not be used Required Undecidable Directive
MisraC2023:D.4.13 Functions which are designed to provide operations on a resource should be called in an appropriate sequence Advisory Undecidable Directive
MisraC2023:D.4.14 The validity of values received from external sources shall be checked Required Undecidable Directive
MisraC2023:D.4.15 Evaluation of floating-point expressions shall not lead to the undetected generation of infinities and NaNs Required Undecidable Directive
MisraC2023:D.5.1 There shall be no data races between threads Required Undecidable Directive
MisraC2023:D.5.2 There shall be no deadlocks between threads Required Undecidable Directive
MisraC2023:D.5.3 There shall be no dynamic thread creation Required Undecidable Directive

MISRA C:2012

The following table shows the CodeSonar warning classes that are associated with the guidelines in MISRA C:2012.

This table is also available in CSV format: Misra2012-mapping.csv.

The information in this table distinguishes between multiple editions of Misra2012.

Misra2012 EditionCategory Decidability Guideline TypeC Warning Classes
Misra2012:1.1 The program shall contain no violations of the standard C syntax and constraints, and shall not exceed the implementation's translation limits allRequired Decidable Rule
Misra2012:1.2 Language extensions should not be used allAdvisory Undecidable Rule
Misra2012:1.3 There shall be no occurrence of undefined or critical unspecified behaviour allRequired Undecidable Rule
Misra2012:1.4 Emergent language features shall not be used [2] and laterRequired Decidable Rule
Misra2012:1.5 Obsolescent language features shall not be used [3] and laterRequired Undecidable Rule
Misra2012:2.1 A project shall not contain unreachable code allRequired Undecidable Rule
Misra2012:2.2 A project shall not contain dead code allRequired Undecidable Rule
Misra2012:2.3 A project should not contain unused type declarations allAdvisory Decidable Rule
Misra2012:2.4 A project should not contain unused tag declarations allAdvisory Decidable Rule
Misra2012:2.5 A project should not contain unused macro definitions allAdvisory Decidable Rule
Misra2012:2.6 A function should not contain unused label declarations allAdvisory Decidable Rule
Misra2012:2.7 A function should not contain unused parameters allAdvisory Decidable Rule
Misra2012:2.8 A project should not contain unused object definitions [4] and laterAdvisory Decidable Rule
Misra2012:3.1 The character sequences /* and // shall not be used within a comment allRequired Decidable Rule
Misra2012:3.2 Line-splicing shall not be used in // comments allRequired Decidable Rule
Misra2012:4.1 Octal and hexadecimal escape sequences shall be terminated allRequired Decidable Rule
Misra2012:4.2 Trigraphs should not be used allAdvisory Decidable Rule
Misra2012:5.1 External identifiers shall be distinct allRequired Decidable Rule
Misra2012:5.2 Identifiers declared in the same scope and name space shall be distinct allRequired Decidable Rule
Misra2012:5.3 An identifier declared in an inner scope shall not hide an identifier declared in an outer scope allRequired Decidable Rule
Misra2012:5.4 Macro identifiers shall be distinct allRequired Decidable Rule
Misra2012:5.5 Identifiers shall be distinct from macro names allRequired Decidable Rule
Misra2012:5.6 A typedef name shall be a unique identifier allRequired Decidable Rule
Misra2012:5.7 A tag name shall be a unique identifier allRequired Decidable Rule
Misra2012:5.8 Identifiers that define objects or functions with external linkage shall be unique allRequired Decidable Rule
Misra2012:5.9 Identifiers that define objects or functions with internal linkage should be unique allAdvisory Decidable Rule
Misra2012:6.1 Bit-fields shall only be declared with an appropriate type allRequired Decidable Rule
Misra2012:6.2 Single-bit named bit fields shall not be of a signed type allRequired Decidable Rule
Misra2012:6.3 A bit field shall not be declared as a member of a union [3] and laterRequired Decidable Rule
Misra2012:7.1 Octal constants shall not be used allRequired Decidable Rule
Misra2012:7.2 A "u" or "U" suffix shall be applied to all integer constants that are represented in an unsigned type allRequired Decidable Rule
Misra2012:7.3 The lowercase character "l" shall not be used in a literal suffix allRequired Decidable Rule
Misra2012:7.4 A string literal shall not be assigned to an object unless the object's type is "pointer to const-qualified char" allRequired Decidable Rule
Misra2012:7.5 The argument of an integer constant macro shall have an appropriate form [3] and laterMandatory Decidable Rule
Misra2012:7.6 The small integer variants of the minimum-width integer constant macros shall not be used [4] and laterRequired Decidable Rule
Misra2012:8.1 Types shall be explicitly specified allRequired Decidable Rule
Misra2012:8.2 Function types shall be in prototype form with named parameters allRequired Decidable Rule
Misra2012:8.3 All declarations of an object or function shall use the same names and type qualifiers allRequired Decidable Rule
Misra2012:8.4 A compatible declaration shall be visible when an object or function with external linkage is defined allRequired Decidable Rule
Misra2012:8.5 An external object or function shall be declared once in one and only one file allRequired Decidable Rule
Misra2012:8.6 An identifier with external linkage shall have exactly one external definition allRequired Decidable Rule
Misra2012:8.7 Functions and objects should not be defined with external linkage if they are referenced in only one translation unit allAdvisory Decidable Rule
Misra2012:8.8 The static storage class specifier shall be used in all declarations of objects and functions that have internal linkage allRequired Decidable Rule
Misra2012:8.9 An object should be declared at block scope if its identifier only appears in a single function allAdvisory Decidable Rule
Misra2012:8.10 An inline function shall be declared with the static storage class allRequired Decidable Rule
Misra2012:8.11 When an array with external linkage is declared, its size should be explicitly specified allAdvisory Decidable Rule
Misra2012:8.12 Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique allRequired Decidable Rule
Misra2012:8.13 A pointer should point to a const-qualified type whenever possible allAdvisory Undecidable Rule
Misra2012:8.14 The restrict type qualifier shall not be used allRequired Decidable Rule
Misra2012:8.15 All declarations of an object with an explicit alignment specification shall specify the same alignment [3] and laterRequired Decidable Rule
Misra2012:8.16 The alignment specification of zero should not appear in an object declaration [3] and laterAdvisory Decidable Rule
Misra2012:8.17 At most one explicit alignment specifier should appear in an object declaration [3] and laterAdvisory Decidable Rule
Misra2012:9.1 The value of an object with automatic storage duration shall not be read before it has been set allMandatory Undecidable Rule
Misra2012:9.2 The initializer for an aggregate or union shall be enclosed in braces allRequired Decidable Rule
Misra2012:9.3 Arrays shall not be partially initialized allRequired Decidable Rule
Misra2012:9.4 An element of an object shall not be initialized more than once allRequired Decidable Rule
Misra2012:9.5 Where designated initializers are used to initialize an array object the size of the array shall be specified explicitly allRequired Decidable Rule
Misra2012:9.6 An initializer using chained designators shall not contain initializers without designators [4] and laterRequired Decidable Rule
Misra2012:9.7 Atomic objects shall be appropriately initialized before being accessed [4] and laterMandatory Undecidable Rule
Misra2012:10.1 Operands shall not be of an inappropriate essential type allRequired Decidable Rule
Misra2012:10.2 Expressions of essentially character type shall not be used inappropriately in addition and subtraction operations allRequired Decidable Rule
Misra2012: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 allRequired Decidable Rule
Misra2012:10.4 Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category allRequired Decidable Rule
Misra2012:10.5 The value of an expression should not be cast to an inappropriate essential type allAdvisory Decidable Rule
Misra2012:10.6 The value of a composite expression shall not be assigned to an object with wider essential type allRequired Decidable Rule
Misra2012:10.7 If a composite expression is used as one operand of an operator in which the usual arithmetic conversions are performed then the other operand shall not have wider essential type allRequired Decidable Rule
Misra2012:10.8 The value of a composite expression shall not be cast to a different essential type category or a wider essential type allRequired Decidable Rule
Misra2012:11.1 Conversions shall not be performed between a pointer to a function and any other type allRequired Decidable Rule
Misra2012:11.2 Conversions shall not be performed between a pointer to an incomplete type and any other type allRequired Decidable Rule
Misra2012:11.3 A conversion shall not be performed between a pointer to object type and a pointer to a different object type allRequired Decidable Rule
Misra2012:11.4 A conversion should not be performed between a pointer to object and an integer type allAdvisory Decidable Rule
Misra2012:11.5 A conversion should not be performed from pointer to void into pointer to object allAdvisory Decidable Rule
Misra2012:11.6 A cast shall not be performed between pointer to void and an arithmetic type allRequired Decidable Rule
Misra2012:11.7 A cast shall not be performed between pointer to object and a non-integer arithmetic type allRequired Decidable Rule
Misra2012:11.8 A conversion shall not remove any const, volatile or _Atomic qualification from the type pointed to by a pointer allRequired Decidable Rule
Misra2012:11.9 The macro NULL shall be the only permitted form of integer null pointer constant allRequired Decidable Rule
Misra2012:11.10 The _Atomic qualifier shall not be applied to the incomplete type void [4] and laterRequired Decidable Rule
Misra2012:12.1 The precedence of operators within expressions should be made explicit allAdvisory Decidable Rule
Misra2012:12.2 The right hand operand of a shift operator shall lie in the range zero to one less than the width in bits of the essential type of the left hand operand allRequired Undecidable Rule
Misra2012:12.3 The comma operator should not be used allAdvisory Decidable Rule
Misra2012:12.4 Evaluation of constant expressions should not lead to unsigned integer wrap-around allAdvisory Decidable Rule
Misra2012:12.5 The sizeof operator shall not have an operand which is a function parameter declared as "array of type" [1] and laterMandatory Decidable Rule
Misra2012:12.6 Structure and union members of atomic objects shall not be directly accessed [4] and laterRequired Decidable Rule
Misra2012:13.1 Initializer lists shall not contain persistent side effects allRequired Undecidable Rule
Misra2012:13.2 The value of an expression and its persistent side effects shall be the same under all permitted evaluation orders and shall be independent from thread interleaving allRequired Undecidable Rule
Misra2012:13.3 A full expression containing an increment (++) or decrement (--) operator should have no other potential side effects other than that caused by the increment or decrement operator allAdvisory Decidable Rule
Misra2012:13.4 The result of an assignment operator should not be used allAdvisory Decidable Rule
Misra2012:13.5 The right hand operand of a logical && or || operator shall not contain persistent side effects allRequired Undecidable Rule
Misra2012:13.6 The operand of the sizeof operator shall not contain any expression which has potential side effects allRequired Decidable Rule
Misra2012:14.1 A loop counter shall not have essentially floating type allRequired Undecidable Rule
Misra2012:14.2 A for loop shall be well-formed allRequired Undecidable Rule
Misra2012:14.3 Controlling expressions shall not be invariant allRequired Undecidable Rule
Misra2012:14.4 The controlling expression of an if statement and the controlling expression of an iteration-statement shall have essentially Boolean type allRequired Decidable Rule
Misra2012:15.1 The goto statement should not be used allAdvisory Decidable Rule
Misra2012:15.2 The goto statement shall jump to a label declared later in the same function allRequired Decidable Rule
Misra2012:15.3 Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement allRequired Decidable Rule
Misra2012:15.4 There should be no more than one break or goto statement used to terminate any iteration statement allAdvisory Decidable Rule
Misra2012:15.5 A function should have a single point of exit at the end allAdvisory Decidable Rule
Misra2012:15.6 The body of an iteration-statement or a selection-statement shall be a compound-statement allRequired Decidable Rule
Misra2012:15.7 All if ... else if constructs shall be terminated with an else statement allRequired Decidable Rule
Misra2012:16.1 All switch statements shall be well-formed allRequired Decidable Rule
Misra2012:16.2 A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement allRequired Decidable Rule
Misra2012:16.3 An unconditional break statement shall terminate every switch-clause allRequired Decidable Rule
Misra2012:16.4 Every switch statement shall have a default label allRequired Decidable Rule
Misra2012:16.5 A default label shall appear as either the first or the last switch label of a switch statement allRequired Decidable Rule
Misra2012:16.6 Every switch statement shall have at least two switch-clauses allRequired Decidable Rule
Misra2012:16.7 A switch-expression shall not have essentially Boolean type allRequired Decidable Rule
Misra2012:17.1 The standard header file <stdarg.h> shall not be used allRequired Decidable Rule
Misra2012:17.2 Functions shall not call themselves, either directly or indirectly allRequired Undecidable Rule
Misra2012:17.3 A function shall not be declared implicitly allMandatory Decidable Rule
Misra2012:17.4 All exit paths from a function with non-void return type shall have an explicit return statement with an expression allMandatory Decidable Rule
Misra2012:17.5 The function argument corresponding to a parameter declared to have an array type shall have an appropriate number of elements allRequired Undecidable Rule
Misra2012:17.6 The declaration of an array parameter shall not contain the static keyword between the [ ] allMandatory Decidable Rule
Misra2012:17.7 The value returned by a function having non-void return type shall be used allRequired Decidable Rule
Misra2012:17.8 A function parameter should not be modified allAdvisory Undecidable Rule
Misra2012:17.9 A function declared with a _Noreturn function specifier shall not return to its caller [3] and laterMandatory Undecidable Rule
Misra2012:17.10 A function declared with a _Noreturn function specifier shall have void return type [3] and laterRequired Decidable Rule
Misra2012:17.11 A function that never returns should be declared with a _Noreturn function specifier [3] and laterAdvisory Undecidable Rule
Misra2012:17.12 A function identifier should only be used with either a preceding &, or with a parenthesized parameter list [3] and laterAdvisory Decidable Rule
Misra2012:17.13 A function type shall not be type qualified [3] and laterRequired Decidable Rule
Misra2012:18.1 A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand allRequired Undecidable Rule
Misra2012:18.2 Subtraction between pointers shall only be applied to pointers that address elements of the same array allRequired Undecidable Rule
Misra2012:18.3 The relational operators >, >=, < and <= shall not be applied to expressions of pointer type except where they point into the same object allRequired Undecidable Rule
Misra2012:18.4 The +, -, += and -= operators should not be applied to an expression of pointer type allAdvisory Decidable Rule
Misra2012:18.5 Declarations should contain no more than two levels of pointer nesting allAdvisory Decidable Rule
Misra2012:18.6 The address of an object with automatic or thread-local storage shall not be copied to another object that persists after the first object has ceased to exist allRequired Undecidable Rule
Misra2012:18.7 Flexible array members shall not be declared allRequired Decidable Rule
Misra2012:18.8 Variable-length array types shall not be used allRequired Decidable Rule
Misra2012:18.9 An object with temporary lifetime shall not undergo array-to-pointer conversion [3] and laterRequired Decidable Rule
Misra2012:18.10 Pointers to variably-modified array types shall not be used [4] and laterMandatory Decidable Rule
Misra2012:19.1 An object shall not be assigned or copied to an overlapping object allMandatory Undecidable Rule
Misra2012:19.2 The union keyword should not be used allAdvisory Decidable Rule
Misra2012:20.1 #include directives should only be preceded by preprocessor directives or comments allAdvisory Decidable Rule
Misra2012:20.2 The ', " or \ characters and the /* or // character sequences shall not occur in a header file name allRequired Decidable Rule
Misra2012:20.3 The #include directive shall be followed by either a <filename> or "filename" sequence allRequired Decidable Rule
Misra2012:20.4 A macro shall not be defined with the same name as a keyword allRequired Decidable Rule
Misra2012:20.5 #undef should not be used allAdvisory Decidable Rule
Misra2012:20.6 Tokens that look like a preprocessing directive shall not occur within a macro argument allRequired Decidable Rule
Misra2012:20.7 Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses allRequired Decidable Rule
Misra2012:20.8 The controlling expression of a #if or #elif preprocessing directive shall evaluate to 0 or 1 allRequired Decidable Rule
Misra2012:20.9 All identifiers used in the controlling expression of #if or #elif preprocessing directives shall be #define'd before evaluation allRequired Decidable Rule
Misra2012:20.10 The # and ## preprocessor operators should not be used allAdvisory Decidable Rule
Misra2012:20.11 A macro parameter immediately following a # operator shall not immediately be followed by a ## operator allRequired Decidable Rule
Misra2012: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 allRequired Decidable Rule
Misra2012:20.13 A line whose first token is # shall be a valid preprocessing directive allRequired Decidable Rule
Misra2012:20.14 All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if, #ifdef or #ifndef directive to which they are related allRequired Decidable Rule
Misra2012:21.1 #define and #undef shall not be used on a reserved identifier or reserved macro name allRequired Decidable Rule
Misra2012:21.2 A reserved identifier or reserved macro name shall not be declared allRequired Decidable Rule
Misra2012:21.3 The memory allocation and deallocation functions of <stdlib.h> shall not be used allRequired Decidable Rule
Misra2012:21.4 The standard header file <setjmp.h> shall not be used allRequired Decidable Rule
Misra2012:21.5 The standard header file <signal.h> shall not be used allRequired Decidable Rule
Misra2012:21.6 The Standard Library input/output functions shall not be used allRequired Decidable Rule
Misra2012:21.7 The atof, atoi, atol and atoll functions of <stdlib.h> shall not be used allRequired Decidable Rule
Misra2012:21.8 The Standard Library termination functions of <stdlib.h> shall not be used allRequired Decidable Rule
Misra2012:21.9 The library functions bsearch and qsort of <stdlib.h> shall not be used allRequired Decidable Rule
Misra2012:21.10 The Standard Library time and date functions shall not be used allRequired Decidable Rule
Misra2012:21.11 The standard header file <tgmath.h> should not be used allAdvisory Decidable Rule
Misra2012:21.12 The standard header file <fenv.h> shall not be used allRequired Decidable Rule
Misra2012:21.13 Any value passed to a function in <ctype.h> shall be representable as an unsigned char or be the value EOF [1] and laterMandatory Undecidable Rule
Misra2012:21.14 The Standard Library function memcmp shall not be used to compare null terminated strings [1] and laterRequired Undecidable Rule
Misra2012:21.15 The pointer arguments to the Standard Library functions memcpy, memmove and memcmp shall be pointers to qualified or unqualified versions of compatible types [1] and laterRequired Decidable Rule
Misra2012:21.16 The pointer arguments to the Standard Library function memcmp shall point to either a pointer type, an essentially signed type, an essentially unsigned type, an essentially Boolean type or an essentially enum type [1] and laterRequired Decidable Rule
Misra2012:21.17 Use of the string handling functions from <string.h> shall not result in accesses beyond the bounds of the objects referenced by their pointer parameters [1] and laterMandatory Undecidable Rule
Misra2012:21.18 The size_t argument passed to any function in <string.h> shall have an appropriate value [1] and laterMandatory Undecidable Rule
Misra2012:21.19 The pointers returned by the Standard Library functions localeconv, getenv, setlocale or, strerror shall only be used as if they have pointer to const-qualified type [1] and laterMandatory Undecidable Rule
Misra2012:21.20 The pointer returned by the Standard Library functions asctime, ctime, gmtime, localtime, localeconv, getenv, setlocale or strerror shall not be used following a subsequent call to the same function [1] and laterMandatory Undecidable Rule
Misra2012:21.21 The Standard Library function system of <stdlib.h> shall not be used [2] and laterRequired Decidable Rule
Misra2012:21.22 All operand arguments to any type-generic macros declared in <tgmath.h> shall have an appropriate essential type [3] and laterMandatory Decidable Rule
Misra2012:21.23 All operand arguments to any multi-argument type-generic macros declared in <tgmath.h> shall have the same standard type [3] and laterRequired Decidable Rule
Misra2012:21.24 The random number generator functions of <stdlib.h> shall not be used [3] and laterRequired Decidable Rule
Misra2012:21.25 All memory synchronization operations shall be executed in sequentially consistent order [4] and laterAdvisory Decidable Rule
Misra2012:21.26 The Standard Library function mtx_timedlock() shall only be invoked on mutex objects of appropriate mutex type [4] and laterRequired Undecidable Rule-
Misra2012:22.1 All resources obtained dynamically by means of Standard Library functions shall be explicitly released allRequired Undecidable Rule
Misra2012:22.2 A block of memory shall only be freed if it was allocated by means of a Standard Library function allMandatory Undecidable Rule
Misra2012:22.3 The same file shall not be open for read and write access at the same time on different streams allRequired Undecidable Rule
Misra2012:22.4 There shall be no attempt to write to a stream which has been opened as read-only allMandatory Undecidable Rule
Misra2012:22.5 A pointer to a FILE object shall not be dereferenced allMandatory Undecidable Rule
Misra2012:22.6 The value of a pointer to a FILE shall not be used after the associated stream has been closed allMandatory Undecidable Rule
Misra2012:22.7 The macro EOF shall only be compared with the unmodified return value from any Standard Library function capable of returning EOF [1] and laterRequired Undecidable Rule
Misra2012:22.8 The value of errno shall be set to zero prior to a call to an errno-setting-function [1] and laterRequired Undecidable Rule
Misra2012:22.9 The value of errno shall be tested against zero after calling an errno-setting-function [1] and laterRequired Undecidable Rule
Misra2012:22.10 The value of errno shall only be tested when the last function to be called was an errno-setting-function [1] and laterRequired Undecidable Rule
Misra2012:22.11 A thread that was previously either joined or detached shall not be subsequently joined nor detached [4] and laterRequired Undecidable Rule
Misra2012:22.12 Thread objects, thread synchronization objects, and thread-specific storage pointers shall only be accessed by the appropriate Standard Library functions [4] and laterMandatory Undecidable Rule
Misra2012:22.13 Thread objects, thread synchronization objects and thread-specific storage pointers shall have appropriate storage duration [4] and laterRequired Decidable Rule
Misra2012:22.14 Thread synchronization objects shall be initialized before being accessed [4] and laterMandatory Undecidable Rule-
Misra2012:22.15 Thread synchronization objects and thread-specific storage pointers shall not be destroyed until after all threads accessing them have terminated [4] and laterRequired Undecidable Rule-
Misra2012:22.16 All mutex objects locked by a thread shall be explicitly unlocked by the same thread [4] and laterRequired Undecidable Rule
Misra2012:22.17 No thread shall unlock a mutex or call cnd_wait() or cnd_timedwait() for a mutex it has not locked before [4] and laterRequired Undecidable Rule
Misra2012:22.18 Non-recursive mutexes shall not be recursively locked [4] and laterRequired Undecidable Rule
Misra2012:22.19 A condition variable shall be associated with at most one mutex object [4] and laterRequired Undecidable Rule-
Misra2012:22.20 Thread-specific storage pointers shall be created before being accessed [4] and laterMandatory Undecidable Rule-
Misra2012:23.1 A generic selection should only be expanded from a macro [3] and laterAdvisory Decidable Rule
Misra2012:23.2 A generic selection that is not expanded from a macro shall not contain potential side effects in the controlling expression [3] and laterRequired Decidable Rule
Misra2012:23.3 A generic selection should contain at least one non-default association [3] and laterAdvisory Decidable Rule
Misra2012:23.4 A generic association shall list an appropriate type [3] and laterRequired Decidable Rule
Misra2012:23.5 A generic selection should not depend on implicit pointer type conversion [3] and laterAdvisory Decidable Rule
Misra2012:23.6 The controlling expression of a generic selection shall have an essential type that matches its standard type [3] and laterRequired Decidable Rule
Misra2012:23.7 A generic selection that is expanded from a macro should evaluate its argument only once [3] and laterAdvisory Decidable Rule
Misra2012:23.8 A default association shall appear as either the first or the last association of a generic selection [3] and laterAdvisory Decidable Rule
Misra2012:D.1.1 Any implementation-defined behaviour on which the output of the program depends shall be documented and understood allRequired Undecidable Directive-
Misra2012:D.2.1 All source files shall compile without any compilation errors allRequired Undecidable Directive
Misra2012:D.3.1 All code shall be traceable to documented requirements allRequired Undecidable Directive-
Misra2012:D.4.1 Run-time failures shall be minimized allRequired Undecidable Directive
Misra2012:D.4.2 All usage of assembly language should be documented allAdvisory Undecidable Directive-
Misra2012:D.4.3 Assembly language shall be encapsulated and isolated allRequired Undecidable Directive
Misra2012:D.4.4 Sections of code should not be "commented out" allAdvisory Undecidable Directive
Misra2012:D.4.5 Identifiers in the same name space with overlapping visibility should be typographically unambiguous allAdvisory Undecidable Directive
Misra2012:D.4.6 typedefs that indicate size and signedness should be used in place of the basic numerical types allAdvisory Undecidable Directive
Misra2012:D.4.7 If a function returns error information, then that error information shall be tested allRequired Undecidable Directive
Misra2012:D.4.8 If a pointer to a structure or union is never dereferenced within a translation unit, then the implementation of the object should be hidden allAdvisory Undecidable Directive-
Misra2012:D.4.9 A function should be used in preference to a function-like macro where they are interchangeable allAdvisory Undecidable Directive
Misra2012:D.4.10 Precautions shall be taken in order to prevent the contents of a header file being included more than once allRequired Undecidable Directive
Misra2012:D.4.11 The validity of values passed to library functions shall be checked allRequired Undecidable Directive
Misra2012:D.4.12 Dynamic memory allocation shall not be used allRequired Undecidable Directive
Misra2012:D.4.13 Functions which are designed to provide operations on a resource should be called in an appropriate sequence allAdvisory Undecidable Directive
Misra2012:D.4.14 The validity of values received from external sources shall be checked [1] and laterRequired Undecidable Directive
Misra2012:D.4.15 Evaluation of floating-point expressions shall not lead to the undetected generation of infinities and NaNs [3] and laterRequired Undecidable Directive
Misra2012:D.5.1 There shall be no data races between threads [4] and laterRequired Undecidable Directive
Misra2012:D.5.2 There shall be no deadlocks between threads [4] and laterRequired Undecidable Directive
Misra2012:D.5.3 There shall be no dynamic thread creation [4] and laterRequired Undecidable Directive

Editions for Misra2012

0 MISRA C:2012 Guidelines for the use of the C language in critical systems
1 MISRA C:2012 Amendment 1 Additional security guidelines for MISRA C:2012
2 MISRA C:2012 Amendment 2 Updates for ISO/IEC 9899:2011 Core functionality
3 MISRA C:2012 Amendment 3 Updates for ISO/IEC 9899:2011/2018 Phase 2 - New C11/C18 features
4 MISRA C:2012 Amendment 4 Updates for ISO/IEC 9899:2011/2018 Phase 3 - Multi-threading and atomics

MISRA C:2004

The following table shows the CodeSonar warning classes that are associated with the guidelines in MISRA C:2004.

This table is also available in CSV format: Misra2004-mapping.csv.

Misra2004 CategoryC Warning Classes
Misra2004:1.1 All code shall conform to ISO/IEC 9899:1990 "Programming languages C", amended and corrected by ISO/IEC 9899/COR1:1995, ISO/IEC 9899/AMD1:1995, and ISO/IEC 9899/COR2:1996 Required
Misra2004:1.2 No reliance shall be placed on undefined or unspecified behaviour Required-
Misra2004:1.3 Multiple compilers and/or languages shall only be used if there is a common defined interface standard for object code to which the languages/compilers/assemblers conform Required-
Misra2004:1.4 The compiler/linker shall be checked to ensure that 31 character significance and case sensitivity are supported for external identifiers Required-
Misra2004:1.5 Floating-point implementations should comply with a defined floating-point standard Advisory-
Misra2004:2.1 Assembly language shall be encapsulated and isolated Required
Misra2004:2.2 Source code shall only use /* ... */ style comments Required
Misra2004:2.3 The character sequence /* shall not be used within a comment Required
Misra2004:2.4 Sections of code should not be "commented out" Advisory
Misra2004:3.1 All usage of implementation-defined behaviour shall be documented Required-
Misra2004:3.2 The character set and the corresponding encoding shall be documented Required-
Misra2004:3.3 The implementation of integer division in the chosen compiler should be determined, documented and taken into account Advisory-
Misra2004:3.4 All uses of the #pragma directive shall be documented and explained Required
Misra2004:3.5 The implementation defined behaviour and packing of bitfields shall be documented if being relied upon Required
Misra2004:3.6 All libraries used in production code shall be written to comply with the provisions of this document, and shall have been subject to appropriate validation Required-
Misra2004:4.1 Only those escape sequences that are defined in the ISO C standard shall be used Required
Misra2004:4.2 Trigraphs shall not be used Required
Misra2004:5.1 Identifiers (internal and external) shall not rely on the significance of more than 31 characters Required
Misra2004:5.2 Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier Required
Misra2004:5.3 A typedef name shall be a unique identifier Required
Misra2004:5.4 A tag name shall be a unique identifier Required
Misra2004:5.5 No object or function identifier with static storage duration should be reused Advisory
Misra2004:5.6 No identifier in one name space should have the same spelling as an identifier in another name space, with the exception of structure member and union member names Advisory-
Misra2004:5.7 No identifier name should be reused Advisory
Misra2004:6.1 The plain char type shall be used only for storage and use of character values Required
Misra2004:6.2 signed and unsigned char type shall be used only for the storage and use of numeric values Required
Misra2004:6.3 typedefs that indicate size and signedness should be used in place of the basic numerical types Advisory
Misra2004:6.4 Bit fields shall only be defined to be of type unsigned int or signed int Required
Misra2004:6.5 Bit fields of signed type shall be at least 2 bits long Required
Misra2004:7.1 Octal constants (other than zero) and octal escape sequences shall not be used Required
Misra2004:8.1 Functions shall have prototype declarations and the prototype shall be visible at both the function definition and call Required
Misra2004:8.2 Whenever an object or function is declared or defined, its type shall be explicitly stated Required
Misra2004:8.3 For each function parameter the type given in the declaration and definition shall be identical, and the return types shall also be identical Required
Misra2004:8.4 If objects or functions are declared more than once their types shall be compatible Required
Misra2004:8.5 There shall be no definitions of objects or functions in a header file Required
Misra2004:8.6 Functions shall be declared at file scope Required
Misra2004:8.7 Objects shall be defined at block scope if they are only accessed from within a single function Required
Misra2004:8.8 An external object or function shall be declared in one and only one file Required
Misra2004:8.9 An identifier with external linkage shall have exactly one external definition Required
Misra2004:8.10 All declarations and definitions of objects or functions at file scope shall have internal linkage unless external linkage is required Required
Misra2004:8.11 The static storage class specifier shall be used in definitions and declarations of objects and functions that have internal linkage Required
Misra2004:8.12 When an array is declared with external linkage, its size shall be stated explicitly or defined implicitly by initialisation Required
Misra2004:9.1 All automatic variables shall have been assigned a value before being used Required
Misra2004:9.2 Braces shall be used to indicate and match the structure in the non-zero initialisation of arrays and structures Required
Misra2004:9.3 In an enumerator list, the "=" construct shall not be used to explicitly initialise members other than the first, unless all items are explicitly initialised Required
Misra2004:10.1 The value of an expression of integer type shall not be implicitly converted to a different underlying type if: (a) it is not a conversion to a wider integer type of the same signedness, or (b) the expression is complex, or (c) the expression is not constant and is a function argument, or (d) the expression is not constant and is a return expression Required
Misra2004:10.2 The value of an expression of floating type shall not be implicitly converted to a different type if: (a) it is not a conversion to a wider floating type, or (b) the expression is complex, or (c) the expression is a function argument, or (d) the expression is a return expression Required
Misra2004:10.3 The value of a complex expression of integer type shall only be cast to a type of the same signedness that is no wider than the underlying type of the expression Required
Misra2004:10.4 The value of a complex expression of floating type shall only be cast to a floating type that is narrower or of the same size Required
Misra2004:10.5 If the bitwise operators ~ and << are applied to an operand of underlying type unsigned char or unsigned short, the result shall be immediately cast to the underlying type of the operand Required
Misra2004:10.6 A "U" suffix shall be applied to all constants of unsigned type Required
Misra2004:11.1 Conversions shall not be performed between a pointer to a function and any type other than an integral type Required
Misra2004:11.2 Conversions shall not be performed between a pointer to object and any type other than an integral type, another pointer to object type or a pointer to void Required
Misra2004:11.3 A cast should not be performed between a pointer type and an integral type Advisory
Misra2004:11.4 A cast should not be performed between a pointer to object type and a different pointer to object type Advisory
Misra2004:11.5 A cast shall not be performed that removes any const or volatile qualification from the type addressed by a pointer Required
Misra2004:12.1 Limited dependence should be placed on C's operator precedence rules in expressions Advisory
Misra2004:12.2 The value of an expression shall be the same under any order of evaluation that the standard permits Required
Misra2004:12.3 The sizeof operator shall not be used on expressions that contain side effects Required
Misra2004:12.4 The right-hand operand of a logical && or || operator shall not contain side effects Required
Misra2004:12.5 The operands of a logical && or || shall be primary-expressions Required-
Misra2004:12.6 The operands of logical operators (&&, || and !) should be effectively Boolean. Expressions that are effectively Boolean should not be used as operands to operators other than (&&, || , !, =, ==, != and ?:) Advisory
Misra2004:12.7 Bitwise operators shall not be applied to operands whose underlying type is signed Required
Misra2004:12.8 The right-hand operand of a shift operator shall lie between zero and one less than the width in bits of the underlying type of the left-hand operand Required
Misra2004:12.9 The unary minus operator shall not be applied to an expression whose underlying type is unsigned Required
Misra2004:12.10 The comma operator shall not be used Required
Misra2004:12.11 Evaluation of constant unsigned integer expressions should not lead to wraparound Advisory
Misra2004:12.12 The underlying bit representations of floating-point values shall not be used Required
Misra2004:12.13 The increment (++) and decrement (--) operators should not be mixed with other operators in an expression Advisory
Misra2004:13.1 Assignment operators shall not be used in expressions that yield a Boolean value Required
Misra2004:13.2 Tests of a value against zero should be made explicit, unless the operand is effectively Boolean Advisory
Misra2004:13.3 Floating-point expressions shall not be tested for equality or inequality Required
Misra2004:13.4 The controlling expression of a for statement shall not contain any objects of floating type Required
Misra2004:13.5 The three expressions of a for statement shall be concerned only with loop control Required
Misra2004:13.6 Numeric variables being used within a for loop for iteration counting shall not be modified in the body of the loop Required
Misra2004:13.7 Boolean operations whose results are invariant shall not be permitted Required
Misra2004:14.1 There shall be no unreachable code Required
Misra2004:14.2 All non-null statements shall either (a) have at least one side-effect however executed, or (b) cause control flow to change Required
Misra2004:14.3 Before preprocessing, a null statement shall only occur on a line by itself; it may be followed by a comment provided that the first character following the null statement is a white-space character Required
Misra2004:14.4 The goto statement shall not be used Required
Misra2004:14.5 The continue statement shall not be used Required
Misra2004:14.6 For any iteration statement there shall be at most one break statement used for loop termination Required
Misra2004:14.7 A function shall have a single point of exit at the end of the function Required
Misra2004:14.8 The statement forming the body of a switch, while, do ... while or for statement shall be a compound statement Required
Misra2004:14.9 An if (expression) construct shall be followed by a compound statement. The else keyword shall be followed by either a compound statement, or another if statement Required
Misra2004:14.10 All if . else if constructs shall be terminated with an else clause Required
Misra2004:15.0 The MISRA C switch syntax shall be used Required
Misra2004:15.1 A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement Required
Misra2004:15.2 An unconditional break statement shall terminate every non-empty switch clause Required
Misra2004:15.3 The final clause of a switch statement shall be the default clause Required
Misra2004:15.4 A switch expression shall not represent a value that is effectively Boolean Required
Misra2004:15.5 Every switch statement shall have at least one case clause Required
Misra2004:16.1 Functions shall not be defined with variable numbers of arguments Required
Misra2004:16.2 Functions shall not call themselves, either directly or indirectly Required
Misra2004:16.3 Identifiers shall be given for all of the parameters in a function prototype declaration Required
Misra2004:16.4 The identifiers used in the declaration and definition of a function shall be identical Required
Misra2004:16.5 Functions with no parameters shall be declared and defined with the parameter list void Required
Misra2004:16.6 The number of arguments passed to a function shall match the number of parameters Required
Misra2004:16.7 A pointer parameter in a function prototype should be declared as pointer to const if the pointer is not used to modify the addressed object Advisory
Misra2004:16.8 All exit paths from a function with non-void return type shall have an explicit return statement with an expression Required
Misra2004:16.9 A function identifier shall only be used with either a preceding &, or with a parenthesised parameter list, which may be empty Required
Misra2004:16.10 If a function returns error information, then that error information shall be tested Required
Misra2004:17.1 Pointer arithmetic shall only be applied to pointers that address an array or array element Required
Misra2004:17.2 Pointer subtraction shall only be applied to pointers that address elements of the same array Required
Misra2004:17.3 >, >=, <, <= shall not be applied to pointer types except where they point to the same array Required
Misra2004:17.4 Array indexing shall be the only allowed form of pointer arithmetic Required
Misra2004:17.5 The declaration of objects should contain no more than 2 levels of pointer indirection Advisory-
Misra2004:17.6 The address of an object with automatic storage shall not be assigned to another object that may persist after the first object has ceased to exist Required
Misra2004:18.1 All structure or union types shall be complete at the end of a translation unit Required-
Misra2004:18.2 An object shall not be assigned to an overlapping object Required
Misra2004:18.3 An area of memory shall not be reused for unrelated purposes Required-
Misra2004:18.4 Unions shall not be used Required
Misra2004:19.1 #include statements in a file should only be preceded by other preprocessor directives or comments Advisory
Misra2004:19.2 Non-standard characters should not occur in header file names in #include directives Advisory
Misra2004:19.3 The #include directive shall be followed by either a <filename> or "filename" sequence Required
Misra2004:19.4 C macros shall only expand to a braced initialiser, a constant, a string literal, a parenthesised expression, a type qualifier, a storage class specifier, or a do-whilezero construct Required
Misra2004:19.5 Macros shall not be #define'd or #undef'd within a block Required
Misra2004:19.6 #undef shall not be used Required
Misra2004:19.7 A function should be used in preference to a function-like macro Advisory
Misra2004:19.8 A function-like macro shall not be invoked without all of its arguments Required-
Misra2004:19.9 Arguments to a function-like macro shall not contain tokens that look like preprocessing directives Required
Misra2004:19.10 In the definition of a function-like macro each instance of a parameter shall be enclosed in parentheses unless it is used as the operand of # or ## Required-
Misra2004:19.11 All macro identifiers in preprocessor directives shall be defined before use, except in #ifdef and #ifndef preprocessor directives and the defined() operator Required
Misra2004:19.12 There shall be at most one occurrence of the # or ## preprocessor operators in a single macro definition Required-
Misra2004:19.13 The # and ## preprocessor operators should not be used Advisory
Misra2004:19.14 The defined preprocessor operator shall only be used in one of the two standard forms Required-
Misra2004:19.15 Precautions shall be taken in order to prevent the contents of a header file being included twice Required
Misra2004:19.16 Preprocessing directives shall be syntactically meaningful even when excluded by the preprocessor Required-
Misra2004:19.17 All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if or #ifdef directive to which they are related Required
Misra2004:20.1 Reserved identifiers, macros and functions in the standard library, shall not be defined, redefined or undefined Required
Misra2004:20.2 The names of standard library macros, objects and functions shall not be reused Required
Misra2004:20.3 The validity of values passed to library functions shall be checked Required
Misra2004:20.4 Dynamic heap memory allocation shall not be used Required
Misra2004:20.5 The error indicator errno shall not be used Required
Misra2004:20.6 The macro offsetof, in library <stddef.h>, shall not be used Required
Misra2004:20.7 The setjmp macro and the longjmp function shall not be used Required
Misra2004:20.8 The signal handling facilities of <signal.h> shall not be used Required
Misra2004:20.9 The input/output library <stdio.h> shall not be used in production code Required
Misra2004:20.10 The library functions atof, atoi and atol from library <stdlib.h> shall not be used Required
Misra2004:20.11 The library functions abort, exit, getenv and system from library <stdlib.h> shall not be used Required
Misra2004:20.12 The time handling functions of library <time.h> shall not be used Required
Misra2004:21.1 Minimisation of run-time failures shall be ensured by the use of at least one of (a) static analysis tools/techniques; (b) dynamic analysis tools/techniques; (c) explicit coding of checks to handle run-time faults Required-

MISRA C Concepts

Essential Type Category

The following extract is reproduced with permission from MISRA-C 2012 section 8.10.2.
Rules related to essential types "do not apply to expressions with a pointer type, unless otherwise specified".

The essential type of an object or expression is defined by its essential type category and size.

The essential type category of an expression reflects its underlying behaviour and may be:

Note: For the purposes of this essential type model, essentially real floating and essentially complex floating are considered to be different essential type categories.

Note: each enumerated type is a unique essentially enum type identified as enum<i>. This allows different enumerated types to be handled as distinct types, which supports a stronger system of type-checking. One exception is the use of an enumerated type to define a Boolean value in C90. Such types are considered to have essentially Boolean type. Another exception is the use of anonymous enumerations as defined in Appendix D. Anonymous enumerations are a way of defining a set of related constant integers and are considered to have an essentially signed type.

When comparing two types of the same type category, the terms wider and narrower are used to describe their relative sizes as measured in bytes. Two different types are sometimes implemented with the same size.

The following table shows how the standard integer types map on to essential type categories.

Essential type category
Boolean character signed unsigned enum<i> floating
real floating complex floating
  • _Bool
  • char
  • signed char
  • signed short
  • signed int
  • signed long
  • signed long long
  • unsigned char
  • unsigned short
  • unsigned int
  • unsigned long
  • unsigned long long
  • named enum
  • float
  • double
  • long double
  • float _Complex
  • double _Complex
  • long double _Complex

Note: Implementations of C99 and later may provide extended integer types, each of which would be allocated a location appropriate to its rank and signedness.

Composite Expression

The following extract is reproduced with permission from MISRA-C 2012 section 8.10.3.

The following are defined as composite operators in this document:

A compound assignment is equivalent to an assignment of the result of its corresponding composite operator.

A composite expression is defined in this document as a non-constant expression which is the direct result of a composite operator.

Note:

Enabling MISRA C Checks

You can enable checks for all MISRA C standards, individual MISRA C standards, or individual warning classes.

Enabling MISRA-C-related Checks

CodeSonar ships with several taxonomy presets for MISRA C.

misra Enables warning classes for C compilation units. A given class C is enabled if all of the following are true.
  • C is closely mapped to one or more rules or directives in one of the following coding standards. (that is, it appears in at least one of the tables above), and
  • no other classes enabled by the preset are more closely related to the same rules or directives, and
  • C is not diagnostic-only (that is, it does not have a DIAG.* mnemonic).
misra_inc A given class is enabled if it meets all the requirements listed for misra and is supported in incremental analysis.
misra2004 As for misra, but with mappings to MISRA C:2004 only.
misra2004_inc A given class is enabled if it meets all the requirements listed for misra2004 and is supported in incremental analysis.
misra2012 As for misra, but with mappings to the latest edition of MISRA C:2012 only.
misra2012_inc A given class is enabled if it meets all the requirements listed for misra2012 and is supported in incremental analysis.
misrac2023 As for misra, but with mappings to MISRA C:2023 only.
misrac2023_inc A given class is enabled if it meets all the requirements listed for misra2023 and is supported in incremental analysis.
misrac2025 As for misra, but with mappings to MISRA C:2025 only.
misrac2025_inc A given class is enabled if it meets all the requirements listed for misra2025 and is supported in incremental analysis.

You can apply the misra preset to the CodeSonar build/analysis as shown in the following table.

Command Line Specify -preset misra as part of your build/analysis command. For example:
codesonar analyze MyProj -preset misra localhost:7340 make
Define as a default preset Copy misra.conf from $CSONAR/codesonar/presets/ to $CSONAR/codesonar/default_presets/.
OR
Use the CodeSonar Configuration Tool Modify Analysis Settings option.
Windows Build Wizard Select misra from the Preset list on screen 2.
Eclipse Plug-In Select misra from the Presets list in the Properties dialog.
Visual Studio Plug-In Select misra from the Presets list in the Project Properties dialog.

Use the same techniques to apply any of the other MISRA-C-related presets.

Enabling Individual Classes

To enable an individual warning class, follow the instructions in the warning class documentation page (linked in the tables above). The requirements will depend on the class: some classes only require a WARNING_FILTER allow rule, but others require additional settings in order to work correctly.

 

To report problems with this documentation, please visit https://support.codesecure.com/.