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.