Coverity Support for MISRA Coding Standards
Fully ensure the safety, Overview reliability, and security Software is eating the world. Industries that have traditionally relied on mechanical, of software written in C electronic, and analog control systems are increasingly replacing them with software- and C++ driven systems. For example, the average car is expected to contain 300 million lines of code in the next decade—up from 100 million lines of code today. But with the growth of software comes the growth of software defects—which can manifest themselves in these systems with tangible and life-threatening consequences. More importantly, malicious actors can deliberately trigger failures for their own purposes.
Highly complex industries involve many vendors and suppliers simultaneously contributing to the software that goes into the final product. Every participant in this software supply chain must reach consensus on coding standards, defect reporting structures, and so on. The confluence of these two factors—increasing complexity in software systems and longer software supply chains—creates the demand for new tools.
The MISRA C and C++ coding standards are widely used in safety-critical industries, such as automotive, medical, military, and aerospace. The standards provide a set of best practices for writing C and C++ code, facilitating the authorship of safe, secure, and portable code. With Coverity® static analysis, Synopsys provides a comprehensive solution for MISRA standard compliance that is scalable from individual developers all the way to complex software supply chains.
| synopsys.com | 1 MISRA C:2004 MISRA C:2004 rule coverage The MISRA C:2004 coding standard supports the C90 language specification. Supported All Percent coverage It was first released in 2004 and consists All 130 142 91.5% of 142 rules: 124 required and 18 advisory. Coverity covers the entire MISRA C:2004 Required 113 124 91.1% standard.* Advisory 17 18 94.4%
* All rules that can be checked by static analysis are supported. MISRA C:2004 contains 12 rules that are not statically checkable, so a total of 130 are implemented (out of 142).
MISRA C:2004 supported rules
Rule Rule name Category Supported Notes All code shall conform to ISO/IEC 9899:1990 “Programming languages — C”, amended and corrected by ISO/IEC 9899/ Rule 1.1 Required Yes COR1:1995, ISO/IEC 9899/AMD1:1995, and ISO/IEC 9899/ COR2:1996. No reliance shall be placed on undefined or unspecified Rule 1.2 Required No behaviour. Multiple compilers and/or languages shall only be used if there This rule is not statically Rule 1.3 is a common defined interface standard for object code to Required No verifiable. which the languages/compilers/assemblers conform. The compiler/linker shall be checked to ensure that 31 character This rule is not statically Rule 1.4 significance and case sensitivity are supported for external Required No verifiable. identifiers. Floating-point implementations should comply with a defined This rule is not statically Rule 1.5 Required No floating-point standard. verifiable. Rule 2.1 Assembly language shall be encapsulated and isolated. Required Yes Rule 2.2 Source code shall only use /* ... */ style comments. Required Yes Rule 2.3 The character sequence /* shall not be used within a comment. Required Yes Rule 2.4 Sections of code should not be “commented out”. Advisory Yes All usage of implementation-defined behaviour shall be This rule is not statically Rule 3.1 Required No documented. verifiable. The character set and the corresponding encoding shall be This rule is not statically Rule 3.2 Required No documented. verifiable. The implementation of integer division in the chosen compiler This rule is not statically Rule 3.3 Advisory No should be determined, documented and taken into account. verifiable. All uses of the #pragma directive shall be documented and This rule is not statically Rule 3.4 Required No explained. verifiable. If it is being relied upon, the implementation defined behaviour This rule is not statically Rule 3.5 Required No and packing of bitfields shall be documented. verifiable. All libraries used in production code shall be written to comply This rule is not statically Rule 3.6 with the provisions of this document, and shall have been Required No verifiable. subject to appropriate validation. Only those escape sequences that are defined in the ISO C Rule 4.1 Required Yes standard shall be used. Rule 4.2 Trigraphs shall not be used. Required Yes
| synopsys.com | 2 Rule Rule name Category Supported Notes Identifiers (internal and external) shall not rely on the Rule 5.1 Required Yes significance of more than 31 characters. Identifiers in an inner scope shall not use the same name as an Rule 5.2 Required Yes identifier in an outer scope, and therefore hide that identifier. Rule 5.3 A typedef name shall be a unique identifier. Required Yes Rule 5.4 A tag name shall be a unique identifier. Required Yes No object or function identifier with static storage duration Rule 5.5 Advisory Yes should be reused. No identifier in one name space should have the same spelling Rule 5.6 as an identifier in another name space, with the exception of Advisory Yes structure member and union member names. Rule 5.7 No identifier name should be reused. Advisory Yes The plain char type shall be used only for the storage and use of Rule 6.1 Required Yes character values. signed and unsigned char type shall be used only for the storage Rule 6.2 Required Yes and use of numeric values. typedefs that indicate size and signedness should be used in Rule 6.3 Advisory Yes place of the basic numerical types. Bit fields shall only be defined to be of type unsigned int or Rule 6.4 Required Yes signed int. Rule 6.5 Bit fields of signed type shall be at least 2 bits long. Required Yes Octal constants (other than zero) and octal escape sequences Rule 7.1 Required Yes shall not be used. Functions shall have prototype declarations and the prototype Rule 8.1 Required Yes shall be visible at both the function definition and call. Whenever an object or function is declared or defined, its type Rule 8.2 Required Yes shall be explicitly stated. For each function parameter the type given in the declaration Rule 8.3 and definition shall be identical, and the return types shall also Required Yes be identical. If objects or functions are declared more than once their types Rule 8.4 Required Yes shall be compatible. There shall be no definitions of objects or functions in a header Rule 8.5 Required Yes file. Rule 8.6 Functions shall be declared at file scope. Required Yes Objects shall be defined at block scope if they are only accessed Rule 8.7 Required Yes from within a single function. An external object or function shall be declared in one and only Rule 8.8 Required Yes one file. An identifier with external linkage shall have exactly one external Rule 8.9 Required Yes definition. All declarations and definitions of objects or functions at file Rule 8.10 scope shall have internal linkage unless external linkage is Required Yes required. The static storage class specifier shall be used in definitions and Rule 8.11 Required Yes declarations of objects and functions that have internal linkage. When an array is declared with external linkage, its size shall be Rule 8.12 Required Yes stated explicitly or defined implicitly by initialisation. All automatic variables shall have been assigned a value before Rule 9.1 Required Yes being used.
| synopsys.com | 3 Rule Rule name Category Supported Notes Braces shall be used to indicate and match the structure in the Rule 9.2 Required Yes non-zero initialisation of arrays and structures. In an enumerator list, the “=” construct shall not be used to Rule 9.3 explicitly initialise members other than the first, unless all items Required Yes are explicitly initialised. 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) Rule 10.1 Required Yes signedness, or 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. 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 Rule 10.2 wider floating type, or (b) the expression is complex, or (c) the Required Yes expression is a function argument, or (d) the expression is a return expression. The value of a complex expression of integer type shall only be Rule 10.3 cast to a type of the same signedness that is no wider than the Required Yes underlying type of the expression. The value of a complex expression of floating type shall only be Rule 10.4 Required Yes cast to a floating type that is narrower or of the same size. If the bitwise operators ~ and << are applied to an operand of Rule 10.5 underlying type unsigned char or unsigned short, the result shall Required Yes be immediately cast to the underlying type of the operand. Rule 10.6 A “U” suffix shall be applied to all constants of unsigned type. Required Yes Conversions shall not be performed between a pointer to a Rule 11.1 Required Yes function and any type other than an integral type. Conversions shall not be performed between a pointer to object Rule 11.2 and any type other than an integral type, another pointer to Required Yes object type or a pointer to void. A cast should not be performed between a pointer type and an Rule 11.3 Advisory Yes integral type. A cast should not be performed between a pointer to object type Rule 11.4 Advisory Yes and a different pointer to object type. A cast shall not be performed that removes any const or volatile Rule 11.5 Required Yes qualification from the type addressed by a pointer. Limited dependence should be placed on C’s operator Rule 12.1 Advisory Yes precedence rules in expressions. The value of an expression shall be the same under any order of Rule 12.2 Required Yes evaluation that the standard permits. The sizeof operator shall not be used on expressions that Rule 12.3 Required Yes contain side effects. The right-hand operand of a logical or operator shall not Rule 12.4 && || Required Yes contain side effects. Rule 12.5 The operands of a logical && or || shall be primary‑expressions. Required Yes The operands of logical operators (&&, || and !) should be effectively Boolean. Expressions that are effectively Boolean Rule 12.6 Advisory Yes should not be used as operands to operators other than (&&, ||, !,=, ==, != and ?:). Bitwise operators shall not be applied to operands whose Rule 12.7 Required Yes underlying type is signed.
| synopsys.com | 4 Rule Rule name Category Supported Notes The right-hand operand of a shift operator shall lie between zero Rule 12.8 and one less than the width in bits of the underlying type of the Required Yes left-hand operand. The unary minus operator shall not be applied to an expression Rule 12.9 Required Yes whose underlying type is unsigned. Rule 12.10 The comma operator shall not be used. Required Yes Evaluation of constant unsigned integer expressions should not Rule 12.11 Advisory Yes lead to wrap-around. The underlying bit representations of floating-point values shall Rule 12.12 Required Yes not be used. The increment (++) and decrement (- -) operators should not be Rule 12.13 Advisory Yes mixed with other operators in an expression. Assignment operators shall not be used in expressions that yield Rule 13.1 Required Yes a Boolean value. Tests of a value against zero should be made explicit, unless the Rule 13.2 Advisory Yes operand is effectively Boolean. Floating-point expressions shall not be tested for equality or Rule 13.3 Required Yes inequality. The controlling expression of a for statement shall not contain Rule 13.4 Required Yes any objects of floating type. The three expressions of a for statement shall be concerned Rule 13.5 Required Yes only with loop control. Numeric variables being used within a for loop for iteration Rule 13.6 Required Yes counting shall not be modified in the body of the loop. Boolean operations whose results are invariant shall not be Rule 13.7 Required Yes permitted. Rule 14.1 There shall be no unreachable code. Required Yes All non-null statements shall either: (a) have at least one side- Rule 14.2 Required Yes effect however executed, or (b) cause control flow to change. Before preprocessing, a null statement shall only occur on a line by itself; it may be followed by a comment provided that Rule 14.3 Required Yes the first character following the null statement is a white-space character. Rule 14.4 The goto statement shall not be used. Required Yes Rule 14.5 The continue statement shall not be used. Required Yes For any iteration statement there shall be at most one break Rule 14.6 Required Yes statement used for loop termination. A function shall have a single point of exit at the end of the Rule 14.7 Required Yes function. The statement forming the body of a switch, while, do ... while or Rule 14.8 Required Yes for statement shall be a compound statement. An if (expression) construct shall be followed by a compound Rule 14.9 statement. The else keyword shall be followed by either a Required Yes compound statement, or another if statement. Rule 14.10 All if ... else if constructs shall be terminated with an else clause. Required Yes Rule 15.0 The MISRA C switch syntax shall be used. Required Yes A switch label shall only be used when the most closely- Rule 15.1 enclosing compound statement is the body of a switch Required Yes statement. An unconditional break statement shall terminate every non- Rule 15.2 Required Yes empty switch clause.
| synopsys.com | 5 Rule Rule name Category Supported Notes The final clause of a switch statement shall be the default Rule 15.3 Required Yes clause. A switch expression shall not represent a value that is effectively Rule 15.4 Required Yes Boolean. Rule 15.5 Every switch statement shall have at least one case clause. Required Yes Functions shall not be defined with a variable number of Rule 16.1 Required Yes arguments. Rule 16.2 Functions shall not call themselves, either directly or indirectly. Required Yes Identifiers shall be given for all of the parameters in a function Rule 16.3 Required Yes prototype declaration. The identifiers used in the declaration and definition of a Rule 16.4 Required Yes function shall be identical. Functions with no parameters shall be declared and defined with Rule 16.5 Required Yes the parameter list void. The number of arguments passed to a function shall match the Rule 16.6 Required Yes number of parameters. A pointer parameter in a function prototype should be declared Rule 16.7 as pointer to const if the pointer is not used to modify the Required Yes addressed object. All exit paths from a function with non-void return type shall Rule 16.8 Required Yes have an explicit return statement with an expression. A function identifier shall only be used with either a preceding , Rule 16.9 & Required Yes or with a parenthesised parameter list, which may be empty. If a function returns error information, then that error Rule 16.10 Required Yes information shall be tested. Pointer arithmetic shall only be applied to pointers that address Rule 17.1 Required Yes an array or array element. Pointer subtraction shall only be applied to pointers that address Rule 17.2 Required Yes elements of the same array. shall not be applied to pointer types except Rule 17.3 >, >=, <, <= Required Yes where they point to the same array. Array indexing shall be the only allowed form of pointer Rule 17.4 Required Yes arithmetic. The declaration of objects should contain no more than 2 levels Rule 17.5 Advisory Yes of pointer indirection. The address of an object with automatic storage shall not be Rule 17.6 assigned to another object that may persist after the first object Required Yes has ceased to exist. All structure and union types shall be complete at the end of a Rule 18.1 Required Yes translation unit. Rule 18.2 An object shall not be assigned to an overlapping object. Required Yes This rule is not statically Rule 18.3 An area of memory shall not be reused for unrelated purposes. Required No verifiable. Rule 18.4 Unions shall not be used. Required Yes #include statements in a file should only be preceded by other Rule 19.1 Advisory Yes preprocessor directives or comments. Non-standard characters should not occur in header file names Rule 19.2 Advisory Yes in #include directives. The #include directive shall be followed by either a
| synopsys.com | 6 Rule Rule name Category Supported Notes C macros shall only expand to a braced initialiser, a constant, Rule 19.4 a string literal, a parenthesised expression, a type qualifier, a Required Yes storage class specifier, or a do-while-zero construct. Rule 19.5 Macros shall not be #define’d or #undef’d within a block. Required Yes Rule 19.6 #undef shall not be used. Required Yes Rule 19.7 A function should be used in preference to a function-like macro. Advisory Yes A function-like macro shall not be invoked without all of its Rule 19.8 Required Yes arguments. Arguments to a function-like macro shall not contain tokens that Rule 19.9 Required Yes look like preprocessing directives. In the definition of a function-like macro each instance of a Rule 19.10 parameter shall be enclosed in parentheses unless it is used as Required Yes the operand of # or ##. All macro identifiers in preprocessor directives shall be defined Rule 19.11 before use, except in #ifdef and #ifndef preprocessor directives Required Yes and the defined() operator. There shall be at most one occurrence of the or operators Rule 19.12 # ## Required Yes in a single macro definition. Rule 19.13 The # and ## operators should not be used. Advisory Yes The defined preprocessor operator shall only be used in one of Rule 19.14 Required Yes the two standard forms. Precautions shall be taken in order to prevent the contents of a Rule 19.15 Required Yes header file being included twice. Preprocessing directives shall be syntactically meaningful even Rule 19.16 Required Yes when excluded by the preprocessor. All #else, #elif and #endif preprocessor directives shall reside Rule 19.17 in the same file as the #if or #ifdef directive to which they are Required Yes related. Reserved identifiers, macros and functions in the standard Rule 20.1 Required Yes library, shall not be defined, redefined or undefined. The names of standard library macros, objects and functions Rule 20.2 Required Yes shall not be reused. The validity of values passed to library functions shall be Rule 20.3 Required Yes checked. Rule 20.4 Dynamic heap memory allocation shall not be used. Required Yes Rule 20.5 The error indicator errno shall not be used. Required Yes Rule 20.6 The macro offsetof, in library
| synopsys.com | 7 MISRA C++:2008 MISRA C++:2008 rule coverage The MISRA C++:2008 coding standard supports the C++ programming language Supported All Percent coverage as defined by the C++03 language specification. It was first released in All 214 228 93.9% June 2008 and consists of 228 rules: 198 Required 196 198 99.0% required, 18 advisory, and 12 document. Advisory 18 18 100.0% Coverity covers the full MISRA C++:2008 standard.** Document 0 12 0.0%
* All rules that can be checked by static analysis are supported. MISRA C++:2008 contains 14 rules that are not statically checkable, so a total of 214 are implemented (out of 228).
MISRA C++:2008 supported rules
Rule Rule name Category Supported Notes Rule 0-1-1 A project shall not contain unreachable code. Required Yes Rule 0-1-2 A project shall not contain infeasible paths. Required Yes Rule 0-1-3 A project shall not contain unused variables. Required Yes A project shall not contain non-volatile POD variables having only Rule 0-1-4 Required Yes one use. Rule 0-1-5 A project shall not contain unused type declarations. Required Yes A project shall not contain instances of non-volatile variables Rule 0-1-6 Required Yes being given values that are never subsequently used. The value returned by a function having a non-void return type Rule 0-1-7 Required Yes that is not an overloaded operator shall always be used. All functions with void return type shall have external side Rule 0-1-8 Required Yes effect(s). Rule 0-1-9 There shall be no dead code. Required Yes Rule 0-1- Every defined function shall be called at least once. Required Yes 10 Rule 0-1- There shall be no unused parameters (named or unnamed) in Required Yes 11 non-virtual functions. There shall be no unused parameters (named or unnamed) in Rule 0-1- the set of parameters for a virtual function and all the functions Required Yes 12 that override it. Rule 0-2-1 An object shall not be assigned to an overlapping object. Required Yes Static analysis cannot Minimization of run-time failures shall be ensured by the use of determine whether the at least one of: (a) static analysis tools/techniques; (b) dynamic Rule 0-3-1 Document No code was written in analysis tools/techniques; (c) explicit coding of checks to handle accordance to a particular run-time faults. development process. If a function generates error information, then that error Rule 0-3-2 Required Yes information shall be tested. Use of scaled-integer or fixed-point arithmetic shall be Documentation cannot be Rule 0-4-1 Document No documented. programmatically analyzed. Compiler and library behaviors in regard to Rule 0-4-2 Use of floating-point arithmetic shall be documented. Document No floating-point arithmetics are out of the scope of static analysis.
| synopsys.com | 8 Rule Rule name Category Supported Notes Compiler and library behaviors in regard to Floating-point implementations shall comply with a defined Rule 0-4-3 Document No floating-point arithmetics floating-point standard. are out of the scope of static analysis. All code shall conform to ISO/IEC 14882:2003 “The C++ Rule 1-0-1 Required No Standard Incorporating Technical Corrigendum 1”. Compiler and linker Multiple compilers shall only be used if they have a common, Rule 1-0-2 Document No behaviors are out of the defined interface. scope of static analysis. The implementation of integer division in the chosen compiler Documentation cannot be Rule 1-0-3 Document No shall be determined and documented. programmatically analyzed. The character set and the corresponding encoding shall be Documentation cannot be Rule 2-2-1 Document No documented. programmatically analyzed. Rule 2-3-1 Trigraphs shall not be used. Required Yes Rule 2-5-1 Digraphs should not be used. Advisory Yes The character sequence /* shall not be used within a C-style Rule 2-7-1 Required Yes comment. Sections of code shall not be “commented out” using C-style Rule 2-7-2 Required Yes comments. Sections of code should not be “commented out” using C++ Rule 2-7-3 Advisory Yes comments. Rule Different identifiers shall be typographically unambiguous. Required Yes 2-10-1 Rule Identifiers declared in an inner scope shall not hide an identifier Required Yes 2-10-2 declared in an outer scope. Rule A typedef name (including qualification, if any) shall be a unique Required Yes 2-10-3 identifier. Rule A class, union or enum name (including qualification, if any) shall Required Yes 2-10-4 be a unique identifier. Rule The identifier name of a non-member object or function with Advisory Yes 2-10-5 static storage duration should not be reused. Rule If an identifier refers to a type, it shall not also refer to an object Required Yes 2-10-6 or a function in the same scope. Rule Only those escape sequences that are defined in ISO/IEC Required Yes 2-13-1 14882:2003 shall be used. Rule Octal constants (other than zero) and octal escape sequences Required Yes 2-13-2 (other than “\0”) shall not be used. Rule A “U” suffix shall be applied to all octal or hexadecimal integer Required Yes 2-13-3 literals of unsigned type. Rule Literal suffixes shall be upper case. Required Yes 2-13-4 Rule Narrow and wide string literals shall not be concatenated. Required Yes 2-13-5 It shall be possible to include any header file in multiple Rule 3-1-1 Required Yes translation units without violating the One Definition Rule. Rule 3-1-2 Functions shall not be declared at block scope. Required Yes When an array is declared, its size shall either be stated explicitly Rule 3-1-3 Required Yes or defined implicitly by initialization. All declarations of an object or function shall have compatible Rule 3-2-1 Required Yes types.
| synopsys.com | 9 Rule Rule name Category Supported Notes Rule 3-2-2 The One Definition Rule shall not be violated. Required Yes A type, object or function that is used in multiple translation Rule 3-2-3 Required Yes units shall be declared in one and only one file. An identifier with external linkage shall have exactly one Rule 3-2-4 Required Yes definition. Objects or functions with external linkage shall be declared in a Rule 3-3-1 Required Yes header file. If a function has internal linkage then all re-declarations shall Rule 3-3-2 Required Yes include the static storage class specifier. An identifier declared to be an object or type shall be defined in a Rule 3-4-1 Required Yes block that minimizes its visibility. The types used for an object, a function return type, or a function Rule 3-9-1 parameter shall be token-for-token identical in all declarations Required Yes and re-declarations. typedefs that indicate size and signedness should be used in Rule 3-9-2 Advisory Yes place of the basic numerical types. The underlying bit representations of floating-point values shall Rule 3-9-3 Required Yes not be used. Expressions with type bool shall not be used as operands to built-in operators other than the assignment operator the Rule 4-5-1 =, Required Yes logical operators &&, ||, !, the equality operators == and !=, the unary & operator, and the conditional operator. Expressions with type enum shall not be used as operands to built-in operators other than the subscript operator , the Rule 4-5-2 [ ] Required Yes assignment operator =, the equality operators == and !=, the unary & operator, and the relational operators <, <=, >, >=. Expressions with type (plain) char and wchar_t shall not be used as operands to built-in operators other than the assignment Rule 4-5-3 Required Yes operator =, the equality operators == and !=, and the unary & operator. Rule NULL shall not be used as an integer value. Required Yes 4-10-1 Rule Literal zero (0) shall not be used as the null-pointer-constant. Required Yes 4-10-2 The value of an expression shall be the same under any order of Rule 5-0-1 Required Yes evaluation that the standard permits. Limited dependence should be placed on C++ operator Rule 5-0-2 Advisory Yes precedence rules in expressions. A cvalue expression shall not be implicitly converted to a Rule 5-0-3 Required Yes different underlying type. An implicit integral conversion shall not change the signedness Rule 5-0-4 Required Yes of the underlying type. Rule 5-0-5 There shall be no implicit floating-integral conversions. Required Yes An implicit integral or floating-point conversion shall not reduce Rule 5-0-6 Required Yes the size of the underlying type. There shall be no explicit floating-integral conversions of a cvalue Rule 5-0-7 Required Yes expression. An explicit integral or floating-point conversion shall not increase Rule 5-0-8 Required Yes the size of the underlying type of a cvalue expression. An explicit integral conversion shall not change the signedness Rule 5-0-9 Required Yes of the underlying type of a cvalue expression.
| synopsys.com | 10 Rule Rule name Category Supported Notes If the bitwise operators and are applied to an operand with Rule 5-0- ~ << an underlying type of unsigned char or unsigned short, the result Required Yes 10 shall be immediately cast to the underlying type of the operand. Rule 5-0- The plain char type shall only be used for the storage and use of Required Yes 11 character values. Rule 5-0- signed char and unsigned char type shall only be used for the Required Yes 12 storage and use of numeric values. Rule 5-0- The condition of an if-statement and the condition of an iteration- Required Yes 13 statement shall have type bool. Rule 5-0- The first operand of a conditional-operator shall have type bool. Required Yes 14 Rule 5-0- Array indexing shall be the only form of pointer arithmetic. Required Yes 15 A pointer operand and any pointer resulting from pointer Rule 5-0- arithmetic using that operand shall both address elements of Required Yes 16 the same array. Rule 5-0- Subtraction between pointers shall only be applied to pointers Required Yes 17 that address elements of the same array. Rule 5-0- shall not be applied to objects of pointer type, >, >=, <, <= Required Yes 18 except where they point to the same array. Rule 5-0- The declaration of objects shall contain no more than two levels Required Yes 19 of pointer indirection. Rule 5-0- Non-constant operands to a binary bitwise operator shall have Required Yes 20 the same underlying type. Rule 5-0- Bitwise operators shall only be applied to operands of unsigned Required Yes 21 underlying type. Rule 5-2-1 Each operand of a logical && or || shall be a postfix-expression. Required Yes A pointer to a virtual base class shall only be cast to a pointer to Rule 5-2-2 Required Yes a derived class by means of dynamic_cast. Casts from a base class to a derived class should not be Rule 5-2-3 Advisory Yes performed on polymorphic types. C-style casts (other than void casts) and functional notation Rule 5-2-4 Required Yes casts (other than explicit constructor calls) shall not be used. A cast shall not remove any const or volatile qualification from Rule 5-2-5 Required Yes the type of a pointer or reference. A cast shall not convert a pointer to a function to any other Rule 5-2-6 Required Yes pointer type, including a pointer to function type. An object with pointer type shall not be converted to an Rule 5-2-7 Required Yes unrelated pointer type, either directly or indirectly. An object with integer type or pointer to void type shall not be Rule 5-2-8 Required Yes converted to an object with pointer type. Rule 5-2-9 A cast should not convert a pointer type to an integral type. Advisory Yes Rule 5-2- The increment (++) and decrement (--) operators should not be Advisory Yes 10 mixed with other operators in an expression. Rule 5-2- The comma operator, operator and the operator shall && || Required Yes 11 not be overloaded. Rule 5-2- An identifier with array type passed as a function argument shall Required Yes 12 not decay to a pointer. Each operand of the operator, the logical or the logical Rule 5-3-1 ! && || Required Yes operators shall have type bool.
| synopsys.com | 11 Rule Rule name Category Supported Notes The unary minus operator shall not be applied to an expression Rule 5-3-2 Required Yes whose underlying type is unsigned. Rule 5-3-3 The unary & operator shall not be overloaded. Required Yes Evaluation of the operand to the sizeof operator shall not contain Rule 5-3-4 Required Yes side effects. The right hand operand of a shift operator shall lie between zero Rule 5-8-1 and one less than the width in bits of the underlying type of the Required Yes left hand operand. Rule The right hand operand of a logical or operator shall not && || Required Yes 5-14-1 contain side effects. Static analysis cannot Rule The semantic equivalence between a binary operator and its reason about high-level Required No 5-17-1 assignment operator form shall be preserved. semantics of the source code. Rule The comma operator shall not be used. Required Yes 5-18-1 Rule Evaluation of constant unsigned integer expressions should not Advisory Yes 5-19-1 lead to wrap-around. Rule 6-2-1 Assignment operators shall not be used in sub-expressions. Required Yes Floating-point expressions shall not be directly or indirectly Rule 6-2-2 Required Yes tested for equality or inequality. Before preprocessing, a null statement shall only occur on a line by itself; it may be followed by a comment, provided that Rule 6-2-3 Required Yes the first character following the null statement is a white-space character. The statement forming the body of a switch, while, do... while or Rule 6-3-1 Required Yes for statement shall be a compound statement. An if ( condition ) construct shall be followed by a compound Rule 6-4-1 statement. The else keyword shall be followed by either a Required Yes compound statement, or another if statement. Rule 6-4-2 All if ... else if constructs shall be terminated with an else clause. Required Yes Rule 6-4-3 A switch statement shall be a well-formed switch statement. Required Yes A switch-label shall only be used when the most closely- Rule 6-4-4 enclosing compound statement is the body of a switch Required Yes statement. An unconditional throw or break statement shall terminate every Rule 6-4-5 Required Yes non-empty switch-clause. The final clause of a switch statement shall be the default- Rule 6-4-6 Required Yes clause. Rule 6-4-7 The condition of a switch statement shall not have bool type. Required Yes Rule 6-4-8 Every switch statement shall have at least one case-clause. Required Yes A for loop shall contain a single loop-counter which shall not Rule 6-5-1 Required Yes have floating type. If loop-counter is not modified by -- or ++, then, within Rule 6-5-2 condition, the loop-counter shall only be used as an operand to Required Yes <=, <, > or >=. The loop-counter shall not be modified within condition or Rule 6-5-3 Required Yes statement. The loop-counter shall be modified by one of: Rule 6-5-4 --, ++, -=n, Required Yes or +=n; where n remains constant for the duration of the loop.
| synopsys.com | 12 Rule Rule name Category Supported Notes A loop-control-variable other than the loop-counter shall not be Rule 6-5-5 Required Yes modified within condition or expression. A loop-control-variable other than the loop-counter which is Rule 6-5-6 Required Yes modified in statement shall have type bool. Any label referenced by a goto statement shall be declared in the Rule 6-6-1 Required Yes same block, or in a block enclosing the goto statement. The goto statement shall jump to a label declared later in the Rule 6-6-2 Required Yes same function body. The continue statement shall only be used within a well-formed Rule 6-6-3 Required Yes for loop. For any iteration statement there shall be no more than one Rule 6-6-4 Required Yes break or goto statement used for loop termination. A function shall have a single point of exit at the end of the Rule 6-6-5 Required Yes function. Rule 7-1-1 A variable which is not modified shall be const qualified. Required Yes A pointer or reference parameter in a function shall be declared Rule 7-1-2 as pointer to const or reference to const if the corresponding Required Yes object is not modified. An expression with enum underlying type shall only have values Rule 7-2-1 Required Yes corresponding to the enumerators of the enumeration. The global namespace shall only contain main, namespace Rule 7-3-1 Required Yes declarations and extern ″C″ declarations. The identifier main shall not be used for a function other than Rule 7-3-2 Required Yes the global function main. Rule 7-3-3 There shall be no unnamed namespaces in header files. Required Yes Rule 7-3-4 using-directives shall not be used. Required Yes Multiple declarations for an identifier in the same namespace Rule 7-3-5 Required Yes shall not straddle a using-declaration for that identifier. using-directives and using-declarations (excluding class scope Rule 7-3-6 or function scope using-declarations) shall not be used in header Required Yes files. Documentation cannot be Rule 7-4-1 All usage of assembler shall be documented. Document No programmatically analyzed. Assembler instructions shall only be introduced using the asm Rule 7-4-2 Required Yes declaration. Rule 7-4-3 Assembly language shall be encapsulated and isolated. Required Yes A function shall not return a reference or a pointer to an Rule 7-5-1 automatic variable (including parameters), defined within the Required Yes function. The address of an object with automatic storage shall not be Rule 7-5-2 assigned to another object that may persist after the first object Required Yes has ceased to exist. A function shall not return a reference or a pointer to a Rule 7-5-3 Required Yes parameter that is passed by reference or const reference. Rule 7-5-4 Functions should not call themselves, either directly or indirectly. Advisory Yes An init-declarator-list or a member-declarator-list shall consist of Rule 8-0-1 Required Yes a single init-declarator or member-declarator respectively. Parameters in an overriding virtual function shall either use the Rule 8-3-1 same default arguments as the function they override, or else Required Yes shall not specify any default arguments. Rule 8-4-1 Functions shall not be defined using the ellipsis notation. Required Yes
| synopsys.com | 13 Rule Rule name Category Supported Notes The identifiers used for the parameters in a re-declaration of a Rule 8-4-2 Required Yes function shall be identical to those in the declaration. All exit paths from a function with non-void return type shall have Rule 8-4-3 Required Yes an explicit return statement with an expression. A function identifier shall either be used to call the function or it Rule 8-4-4 Required Yes shall be preceded by &. Rule 8-5-1 All variables shall have a defined value before they are used. Required Yes Braces shall be used to indicate and match the structure in the Rule 8-5-2 Required Yes non-zero initialization of arrays and structures. In an enumerator list, the = construct shall not be used to Rule 8-5-3 explicitly initialize members other than the first, unless all items Required Yes are explicitly initialized. const member functions shall not return non-const pointers or Rule 9-3-1 Required Yes references to class-data. Member functions shall not return non-const handles to class- Rule 9-3-2 Required Yes data. If a member function can be made static then it shall be made Rule 9-3-3 static, otherwise if it can be made const then it shall be made Required Yes const. Rule 9-5-1 Unions shall not be used. Required Yes When the absolute positioning of bits representing a bit-field is Documentation cannot be Rule 9-6-1 required, then the behaviour and packing of bit-fields shall be Document No programmatically analyzed. documented. Bit-fields shall be either bool type or an explicitly unsigned or Rule 9-6-2 Required Yes signed integral type. Rule 9-6-3 Bit-fields shall not have enum type. Required Yes Named bit-fields with signed integer type shall have a length of Rule 9-6-4 Required Yes more than one bit. Rule 10- Classes should not be derived from virtual bases. Advisory Yes 1-1 Rule 10- A base class shall only be declared virtual if it is used in a Required Yes 1-2 diamond hierarchy. Rule 10- An accessible base class shall not be both virtual and non-virtual Required Yes 1-3 in the same hierarchy. Rule 10- All accessible entity names within a multiple inheritance Advisory Yes 2-1 hierarchy should be unique. Rule 10- There shall be no more than one definition of each virtual Required Yes 3-1 function on each path through the inheritance hierarchy. Rule 10- Each overriding virtual function shall be declared with the virtual Required Yes 3-2 keyword. Rule 10- A virtual function shall only be overridden by a pure virtual Required Yes 3-3 function if it is itself declared as pure virtual. Rule 11- Member data in non-POD class types shall be private. Required Yes 0-1 Rule 12- An object’s dynamic type shall not be used from the body of its Required Yes 1-1 constructor or destructor. Rule 12- All constructors of a class should explicitly call a constructor for Advisory Yes 1-2 all of its immediate base classes and all virtual base classes. Rule 12- All constructors that are callable with a single argument of Required Yes 1-3 fundamental type shall be declared explicit.
| synopsys.com | 14 Rule Rule name Category Supported Notes Rule 12- A copy constructor shall only initialize its base classes and the Required Yes 8-1 non-static members of the class of which it is a member. Rule 12- The copy assignment operator shall be declared protected or Required Yes 8-2 private in an abstract class. Rule 14- A non-member generic function shall only be declared in a Required Yes 5-1 namespace that is not an associated namespace. Rule 14- A copy constructor shall be declared when there is a template Required Yes 5-2 constructor with a single parameter that is a generic parameter. A copy assignment operator shall be declared when there is a Rule 14- template assignment operator with a parameter that is a generic Required Yes 5-3 parameter. In a class template with a dependent base, any name that may Rule 14- be found in that dependent base shall be referred to using a Required Yes 6-1 qualified-id or this-> Rule 14- The function chosen by overload resolution shall resolve to a Required Yes 6-2 function declared previously in the translation unit. All class templates, function templates, class template Rule 14- member functions and class template static members shall be Required Yes 7-1 instantiated at least once. For any given template specialization, an explicit instantiation Rule 14- of the template with the template-arguments used in the Required Yes 7-2 specialization shall not render the program ill-formed. All partial and explicit specializations for a template shall be Rule 14- declared in the same file as the declaration of their primary Required Yes 7-3 template. Rule 14- Overloaded function templates shall not be explicitly specialized. Required Yes 8-1 The viable function set for a function call should either Rule 14- contain no function specializations, or only contain function Advisory Yes 8-2 specializations. Rule 15- Documentation cannot be Exceptions shall only be used for error handling. Document No 0-1 programmatically analyzed. Rule 15- An exception object should not have pointer type. Advisory Yes 0-2 Rule 15- Control shall not be transferred into a try or catch block using a Required Yes 0-3 goto or a switch statement. Rule 15- The assignment-expression of a throw statement shall not itself Required Yes 1-1 cause an exception to be thrown. Rule 15- NULL shall not be thrown explicitly. Required Yes 1-2 Rule 15- An empty throw shall only be used in the compound- (throw;) Required Yes 1-3 statement of a catch handler. Rule 15- Exceptions shall be raised only after start-up and before Required Yes 3-1 termination of the program. Rule 15- There should be at least one exception handler to catch all Advisory Yes 3-2 otherwise unhandled exceptions Handlers of a function-try-block implementation of a class Rule 15- constructor or destructor shall not reference non-static Required Yes 3-3 members from this class or its bases. Rule 15- Each exception explicitly thrown in the code shall have a handler Required Yes 3-4 of a compatible type in all call paths that could lead to that point.
| synopsys.com | 15 Rule Rule name Category Supported Notes Rule 15- A class type exception shall always be caught by reference. Required Yes 3-5 Where multiple handlers are provided in a single try-catch Rule 15- statement or function-try-block for a derived class and some or Required Yes 3-6 all of its bases, the handlers shall be ordered most-derived to base class. Where multiple handlers are provided in a single try-catch Rule 15- statement or function-try-block, any ellipsis (catch-all) handler Required Yes 3-7 shall occur last. If a function is declared with an exception-specification, then all Rule 15- declarations of the same function (in other translation units) Required Yes 4-1 shall be declared with the same set of type-ids. Rule 15- A class destructor shall not exit with an exception. Required Yes 5-1 Where a function’s declaration includes an exception- Rule 15- specification, the function shall only be capable of throwing Required Yes 5-2 exceptions of the indicated type(s). Rule 15- The terminate() function shall not be called implicitly. Required Yes 5-3 Rule 16- #include directives in a file shall only be preceded by other Required Yes 0-1 preprocessor directives or comments. Rule 16- Macros shall only be #define’d or #undef’d in the global Required Yes 0-2 namespace. Rule 16- #undef shall not be used. Required Yes 0-3 Rule 16- Function-like macros shall not be defined. Required Yes 0-4 Rule 16- Arguments to a function-like macro shall not contain tokens that Required Yes 0-5 look like preprocessing directives. In the definition of a function-like macro, each instance of a Rule 16- parameter shall be enclosed in parentheses, unless it is used as Required Yes 0-6 the operand of # or ##. Undefined macro identifiers shall not be used in #if or #elif Rule 16- preprocessor directives, except as operands to the defined Required Yes 0-7 operator. Rule 16- If the # token appears as the first token on a line, then it shall be Required Yes 0-8 immediately followed by a preprocessing token. Rule 16- The defined preprocessor operator shall only be used in one of Required Yes 1-1 the two standard forms. All #else, #elif and #endif preprocessor directives shall reside Rule 16- in the same file as the #if or #ifdef directive to which they are Required Yes 1-2 related. Rule 16- The pre-processor shall only be used for file inclusion and Required Yes 2-1 include guards. Rule 16- C++ macros shall only be used for include guards, type qualifiers, Required Yes 2-2 or storage class specifiers. Rule 16- Include guards shall be provided. Required Yes 2-3 Rule 16- The ′,″,/* or // characters shall not occur in a header file name. Required Yes 2-4 Rule 16- The \ character should not occur in a header file name. Advisory Yes 2-5
| synopsys.com | 16 Rule Rule name Category Supported Notes Rule 16- The #include directive shall be followed by either a
| synopsys.com | 17 for ISO/IEC 9899:2011. Coverity covers the entire MISRA C:2012 standard, including MISRA C:2012 Amendments 1 and 2.*
The MISRA C:2012 coding standard * All rules that can be checked by static analysis are supported. MISRA C:2012 contains 6 rules that are not statically checkable, so a supports the C90 and C99 language total of 169 are implemented (out of 175) specifications. MISRA C:2012 MISRA C:2012 rule coverage Amendment 1 was released in 2016 and consists of 173 guidelines: 156 rules Decidable Undecidable Subtotal Percent and 17 directives. In addition, checker coverage implementations adhere to the Technical Supported All Supported All Supported All Corrigendum 1, released in July 2017. All 121 121 48 54 169 175 96.6% Amendment 2 was announced in 2020 and adds 2 new rules, making it to a Mandatory 5 5 11 11 16 16 100.0% total of 175 guidelines: 158 rules and 88 88 27 32 113 118 95.8% 17 directives. The two new rules in Required Amendment 2 introduce the support Advisory 28 28 10 11 38 39 97.4%
MISRA C:2012 supported rules
Rule Rule name Category Decidability Supported Notes Any implementation-defined behaviour on which Directive This directive is not the output of the program depends shall be Required Undecidable No 1.1 statically verifiable. documented and understood No checker, but a Directive All source files shall compile without any Required Undecidable No successful analysis run 2.1 compilation errors confirms compliance. Directive All code shall be traceable to documented This directive is not Required Undecidable No 3.1 requirements statically verifiable. No checker, but the use of Directive MISRA analysis will assist Run-time failures shall be minimized Required Undecidable No 4.1 in minimizing runtime failures. Directive All usage of assembly language should be This directive is not Advisory Undecidable No 4.2 documented statically verifiable. Directive Assembly language shall be encapsulated and Required Undecidable Yes 4.3 isolated Directive Sections of code should not be “commented Advisory Undecidable Yes 4.4 out” Identifiers in the same name space with Directive overlapping visibility should be typographically Advisory Undecidable Yes 4.5 unambiguous typedefs that indicate size and signedness Directive Adheres to Technical should be used in place of the basic numerical Advisory Undecidable Yes 4.6 Corrigendum 1. types Directive If a function returns error information, then that Required Undecidable Yes 4.7 error information shall be tested If a pointer to a structure or union is never Directive Adheres to Technical dereferenced within a translation unit, then the Advisory Undecidable Yes 4.8 Corrigendum 1. implementation of the object should be hidden A function should be used in preference Directive to a function-like macro where they are Advisory Undecidable Yes 4.9 interchangeable
| synopsys.com | 18 Rule Rule name Category Decidability Supported Notes Precautions shall be taken in order to prevent Directive the contents of a header file being included more Required Undecidable Yes 4.10 than once Directive The validity of values passed to library functions Adheres to Technical Required Undecidable Yes 4.11 shall be checked Corrigendum 1. Directive Dynamic memory allocation shall not be used Required Undecidable Yes 4.12 Functions which are designed to provide Directive operations on a resource should be called in an Advisory Undecidable Yes 4.13 appropriate sequence Directive The validity of values received from external New directive in Required Undecidable Yes 4.14 sources shall be checked Amendment 1. The program shall contain no violations of the No checker, but a Rule 1.1 standard C syntax and constraints, and shall not Required Decidable Yes successful analysis run exceed the implementation’s translation limits confirms compliance. Rule 1.2 Language extensions should not be used Advisory Undecidable Yes There shall be no occurrence of undefined or Rule 1.3 Required Undecidable No critical unspecified behaviour Rule 1.4 Emergent language features shall not be used Required Decidable Yes New rule in Amendment 2. Rule 2.1 A project shall not contain unreachable code Required Undecidable Yes Adheres to Technical Rule 2.2 There shall be no dead code Required Undecidable Yes Corrigendum 1. A project should not contain unused type Rule 2.3 Advisory Decidable Yes declarations A project should not contain unused tag Rule 2.4 Advisory Decidable Yes declarations A project should not contain unused macro Adheres to Technical Rule 2.5 Advisory Decidable Yes declarations Corrigendum 1. A function should not contain unused label Rule 2.6 Advisory Decidable Yes declarations There should be no unused parameters in Rule 2.7 Advisory Decidable Yes functions The character sequences /* and // shall not be Rule 3.1 Required Decidable Yes used within a comment Rule 3.2 Line-splicing shall not be used in // comments Required Decidable Yes Octal and hexadecimal escape sequences shall Rule 4.1 Required Decidable Yes be terminated Rule 4.2 Trigraphs should not be used Advisory Decidable Yes Rule 5.1 External identifiers shall be distinct Required Decidable Yes Identifiers declared in the same scope and name Rule 5.2 Required Decidable Yes space shall be distinct An identifier declared in an inner scope shall not Rule 5.3 Required Decidable Yes hide an identifier declared in an outer scope Rule 5.4 Macro identifiers shall be distinct Required Decidable Yes Rule 5.5 Identifiers shall be distinct from macro names Required Decidable Yes Rule 5.6 A typedef name shall be a unique identifier Required Decidable Yes Rule 5.7 A tag name shall be a unique identifier Required Decidable Yes Identifiers that define objects or functions with Rule 5.8 Required Decidable Yes external linkage shall be unique
| synopsys.com | 19 Rule Rule name Category Decidability Supported Notes Identifiers that define objects or functions with Adheres to Technical Rule 5.9 Advisory Decidable Yes internal linkage should be unique Corrigendum 1. Bit-fields shall only be declared with an Rule 6.1 Required Decidable Yes appropriate type Single-bit named bit fields shall not be of a Rule 6.2 Required Decidable Yes signed type Rule 7.1 Octal constants shall not be used Required Decidable Yes A “u” or “U” suffix shall be applied to all integer Rule 7.2 constants that are represented in an unsigned Required Decidable Yes type The lowercase character “l” shall not be used in Rule 7.3 Required Decidable Yes a literal suffix A string literal shall not be assigned to an object This rule was updated in Rule 7.4 unless the object’s type is “pointer to const- Required Decidable Yes Amendment 2. qualified char” Rule 8.1 Types shall be explicitly specified Required Decidable Yes Function types shall be in prototype form with Rule 8.2 Required Decidable Yes named parameters All declarations of an object or function shall use Rule 8.3 Required Decidable Yes the same names and type qualifiers A compatible declaration shall be visible when Adheres to Technical Rule 8.4 an object or function with external linkage is Required Decidable Yes Corrigendum 1. defined An external object or function shall be declared Rule 8.5 Required Decidable Yes once in one and only one file An identifier with external linkage shall have Rule 8.6 Required Decidable Yes exactly one external definition Functions and objects should not be defined Rule 8.7 with external linkage if they are referenced in Advisory Decidable Yes only one translation unit The static storage class specifier shall be used Rule 8.8 in all declarations of objects and functions that Required Decidable Yes have internal linkage An object should be defined at block scope if its Rule 8.9 Advisory Decidable Yes identifier only appears in a single function An inline function shall be declared with the Rule 8.10 Required Decidable Yes static storage class When an array with external linkage is declared, Rule 8.11 Advisory Decidable Yes its size should be explicitly specified Within an enumerator list, the value of an Rule 8.12 implicitly-specified enumeration constant shall Required Decidable Yes be unique A pointer should point to a const-qualified type Rule 8.13 Advisory Undecidable Yes whenever possible Rule 8.14 The restrict type qualifier shall not be used Required Decidable Yes The value of an object with automatic storage Rule 9.1 Mandatory Undecidable Yes duration shall not be read before it has been set The initializer for an aggregate or union shall be Rule 9.2 Required Decidable Yes enclosed in braces Rule 9.3 Arrays shall not be partially initialized Required Decidable Yes
| synopsys.com | 20 Rule Rule name Category Decidability Supported Notes An element of an object shall not be in initialized Rule 9.4 Required Decidable Yes more than once Where designated initializers are used to Rule 9.5 initialize an array object the size of the array Required Decidable Yes shall be specified explicitly Operands shall not be of an inappropriate Adheres to Technical Rule 10.1 Required Decidable Yes essential type Corrigendum 1. Expressions of essentially character type shall Rule 10.2 not be used inappropriately in addition and Required Decidable Yes subtraction operations The value of an expression shall not be assigned Adheres to Technical Rule 10.3 to an object with a narrower essential type or of Required Decidable Yes Corrigendum 1. a different essential type category Both operands of an operator in which the usual Adheres to Technical Rule 10.4 arithmetic conversions are performed shall have Required Decidable Yes Corrigendum 1. the same essential type category The value of an expression should not be cast to Adheres to Technical Rule 10.5 Advisory Decidable Yes an inappropriate essential type Corrigendum 1. The value of a composite expression shall not be Rule 10.6 Required Decidable Yes assigned to an object with wider essential type If a composite expression is used as one operand of an operator in which the usual Rule 10.7 Required Decidable Yes arithmetic conversions are performed then the other operand shall not have wider essential type The value of a composite expression shall not Adheres to Technical Rule 10.8 be cast to a different essential type category or a Required Decidable Yes Corrigendum 1. wider essential type Conversions shall not be performed between a Rule 11.1 Required Decidable Yes pointer to a function and any other type Conversions shall not be performed between a Adheres to Technical Rule 11.2 Required Decidable Yes pointer to an incomplete type and any other type Corrigendum 1. A cast shall not be performed between a pointer Rule 11.3 to object type and a pointer to a different object Required Decidable Yes type A conversion should not be performed between Adheres to Technical Rule 11.4 Advisory Decidable Yes a pointer to object and an integer type Corrigendum 1. A conversion should not be performed from Rule 11.5 Advisory Decidable Yes pointer to void into pointer to object A cast shall not be performed between pointer Rule 11.6 Required Decidable Yes to void and an arithmetic type A cast shall not be performed between pointer Rule 11.7 Required Decidable Yes to object and a non-integer arithmetic type A cast shall not remove any const or volatile Rule 11.8 qualification from the type pointed to by a Required Decidable Yes pointer The macro shall be the only permitted Adheres to Technical Rule 11.9 NULL Required Decidable Yes form of integer null pointer constant Corrigendum 1. The precedence of operators within expressions This rule was updated in Rule 12.1 Advisory Decidable Yes should be made explicit Amendment 2. The right hand operand of a shift operator shall Rule 12.2 lie in the range zero to one less than the width in Required Undecidable Yes bits of the essential type of the left hand operand
| synopsys.com | 21 Rule Rule name Category Decidability Supported Notes Rule 12.3 The comma operator should not be used Advisory Decidable Yes Evaluation of constant expressions should not Adheres to Technical Rule 12.4 Advisory Decidable Yes lead to unsigned integer wrap-around Corrigendum 1. The sizeof operator shall not have an operand Rule 12.5 which is a function parameter declared as “array Mandatory Decidable Yes New rule in Amendment 1. of type” Initializer lists shall not contain persistent side Rule 13.1 Required Undecidable Yes effects The value of an expression and its persistent Adheres to Technical Rule 13.2 side effects shall be the same under all Required Undecidable Yes Corrigendum 1. permitted evaluation orders A full expression containing an increment (++) or decrement (--) operator should have no other Rule 13.3 Advisory Decidable Yes potential side effects other than that caused by the increment or decrement operator The result of an assignment operator should not Rule 13.4 Advisory Decidable Yes be used The right hand operand of a logical or Rule 13.5 && || Required Undecidable Yes operator shall not contain persistent side effects The operand of the sizeof operator shall not Rule 13.6 contain any expression which has potential Mandatory Decidable Yes side effects A loop counter shall not have essentially floating Rule 14.1 Required Undecidable Yes type Adheres to Technical Rule 14.2 A for loop shall be well-formed Required Undecidable Yes Corrigendum 1. Rule 14.3 Controlling expressions shall not be invariant Required Undecidable Yes The controlling expression of an if statement and the controlling expression of an Rule 14.4 Required Decidable Yes iteration-statement shall have essentially Boolean type Rule 15.1 The goto statement should not be used Advisory Decidable Yes The goto statement shall jump to a label Rule 15.2 Required Decidable Yes declared later in the same function Any label referenced by a goto statement shall Rule 15.3 be declared in the same block, or in any block Required Decidable Yes enclosing the goto statement There should be no more than one break or Rule 15.4 goto statement used to terminate any iteration Advisory Decidable Yes statement A function should have a single point of exit at Rule 15.5 Advisory Decidable Yes the end The body of an iteration-statement Adheres to Technical Rule 15.6 or a selection-statement shall be a Required Decidable Yes Corrigendum 1. compound-statement All if ... else if constructs shall be terminated with Adheres to Technical Rule 15.7 Required Decidable Yes an else statement Corrigendum 1. Adheres to Technical Rule 16.1 All switch statements shall be well-formed Required Decidable Yes Corrigendum 1. A switch label shall only be used when the most Rule 16.2 closely-enclosing compound statement is the Required Decidable Yes body of a switch statement
| synopsys.com | 22 Rule Rule name Category Decidability Supported Notes An unconditional break statement shall Rule 16.3 Required Decidable Yes terminate every switch-clause Rule 16.4 Every switch statement shall have a default label Required Decidable Yes A default label shall appear as either the first or Rule 16.5 Required Decidable Yes the last switch label of a switch statement Every switch statement shall have at least two Rule 16.6 Required Decidable Yes switch-clauses A switch-expression shall not have Rule 16.7 Required Decidable Yes essentially Boolean type Rule 17.1 The features of
| synopsys.com | 23 Rule Rule name Category Decidability Supported Notes The #include directive shall be followed by either Rule 20.3 Required Decidable Yes a
| synopsys.com | 24 Rule Rule name Category Decidability Supported Notes The library functions bsearch and qsort of Adheres to Technical Rule 21.9 Required Decidable Yes
| synopsys.com | 25 Rule Rule name Category Decidability Supported Notes The value of a pointer to a FILE shall not be Rule 22.6 used after the associated stream has been Mandatory Undecidable Yes closed The macro EOF shall only be compared with Rule 22.7 the unmodified return value from any Standard Required Undecidable Yes New rule in Amendment 1. Library function capable of returning EOF The value of shall be set to zero prior to a Rule 22.8 errno Required Undecidable Yes New rule in Amendment 1. call to an errno-setting-function The value of shall be tested against zero Rule 22.9 errno Required Undecidable Yes New rule in Amendment 1. after calling an errno-setting-function The value of errno shall only be tested Rule 22.10 when the last function to be called was an Required Undecidable Yes New rule in Amendment 1. errno-setting-function This datasheet applies to Coverity 2021.9.0 and later versions.
The Synopsys difference Synopsys helps development teams build secure, high-quality software, minimizing risks while maximizing speed and productivity. Synopsys, a recognized leader in application security, provides static analysis, software composition analysis, and dynamic analysis solutions that enable teams to quickly find and fix vulnerabilities and defects in proprietary code, open source components, and application behavior.
For more information about the Synopsys Synopsys, Inc. U.S. Sales: 800.873.8193 Software Integrity Group, visit us online at 690 E Middlefield Road International Sales: +1 415.321.5237 Email: www.synopsys.com/software. Mountain View, CA 94043 USA [email protected]
©2021 Synopsys, Inc. All rights reserved. Synopsys is a trademark of Synopsys, Inc. in the United States and other countries. A list of Synopsys trademarks is available at www.synopsys.com/copyright.html . All other names mentioned herein are trademarks or registered trademarks of their respective owners. September 2021
| synopsys.com | 26