CodeCheck Documentation
CodeCheck Documentation - MISRA C 2004

Standard: MISRA C 2004

The The Motor Industry Software Reliability Association (MISRA) guidelines for C published in 2004

MISRA Mission Statement: To provide assistance to the automotive industry in the application and creation within vehicle systems of safe and reliable software.

MISRA, The Motor Industry Software Reliability Association, is a collaboration between vehicle manufacturers, component suppliers and engineering consultancies which seeks to promote best practice in developing safety-related electronic systems in road vehicles and other embedded systems. To this end MISRA publishes documents that provide accessible information for engineers and management, and holds events to permit the exchange of experiences between practitioners.

The first edition of the MISRA C Standard was published in 1998, the second edition was released in 2004 with many substantial changes.

www.misra.org.uk

© MIRA Limited, 2004, 2008.

All RulesAdvisory RulesRequired Rules
Understand % Coverage99%100%99%
Understand Coverage861274
Total Rules871275
Check IDCheck NameSupportedCategory
MISRA04_2.12.1 Assembly language shall be encapsulated and isolated.YesRequired
MISRA04_2.22.2 only use /* commentsYesRequired
MISRA04_2.32.3 The character sequence /* shall not be used within a comment.YesRequired
MISRA04_2.42.4 Sections of code should not be "commented out"YesAdvisory
MISRA04_4.14.1 Only those escape sequences that are defined in the ISO C standard shall be usedYesRequired
MISRA04_4.24.2 Trigraphs shall not be usedYesRequired
MISRA04_5.15.1 Identifiers shall not rely on the significance of more than 31 charactersYesRequired
MISRA04_5.25.2 Shadowed IdentifiersYesRequired
MISRA04_5.35.3 A typedef name shall be a unique identifier.YesRequired
MISRA04_5.45.4 A tag name shall be a unique identifierYesRequired
MISRA04_5.55.5 No object or function identifier with static storage duration should be reusedYesAdvisory
MISRA04_5.65.6 No identifier in one name space should have the same spelling as an identifier in another name space.YesAdvisory
MISRA04_5.75.7 No identifier name should be reusedYesAdvisory
MISRA04_6.16.1 The plain char type shall only be used for the storage and use of character valuesYesRequired
MISRA04_6.26.2 Signed char and unsigned char type shall only be used for the storage and use of numeric valuesYesRequired
MISRA04_6.36.3 Typedefs that indicate size and signedness should be used in place of the basic numerical typesYesAdvisory
MISRA04_6.46.4 Bit fields shall only be defined to be of type unsigned int or signed int.YesRequired
MISRA04_6.56.5 Bit fields of signed type shall be at least 2 bits long.( Fuzzy parser )YesRequired
MISRA04_7.17.1 Octal constants (other than zero) and octal escape sequences shall not be used.YesRequired
MISRA04_8.38.3 For each function parameter the type given in the declaration and definition shall be identical, and the return types shall also be identicalYesRequired
MISRA04_8.58.5 No definitions of objects or functions in a header fileYesRequired
MISRA04_8.68.6 Functions shall be declared at file scopeYesRequired
MISRA04_8.78.7 Objects shall be local if only accessed from one functionYesRequired
MISRA04_8.88.8 An external object or function shall be declared in one and only one fileYesRequired
MISRA04_8.98.9 An identifier with external linkage shall have exactly one external definitionYesRequired
MISRA04_8.108.10 prefer internal linkage over external whenever possibleYesRequired
MISRA04_8.118.11 Use the static keyword for internal linkageYesRequired
MISRA04_8.128.12 When an array is declared with external linkage, its size shall be stated explicitly or defined implicitly by initialisationYesRequired
MISRA04_9.39.3 = construct in enumerator list shall only be used on either the first item alone, or all items explicitly.YesRequired
MISRA04_10.510.5 If the bitwise operators ~ and << are applied to an operand with an underlying type of unsigned char or unsigned short, the result shall be immediately cast to the underlying type of the operandYesRequired
MISRA04_10.610.6 A U suffix shall be applied to all constants of unsigned typeYesRequired
MISRA04_12.612.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 ?:)YesAdvisory
MISRA04_12.812.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.YesRequired
MISRA04_12.1212.12 The underlying bit representations of floating-point values shall not be usedYesRequired
MISRA04_12.1312.13 The increment (++) and decrement (--) operators should not be mixed with other operators in an expressionYesAdvisory
MISRA04_13.313.3 Floating-point expressions shall not be tested for equality or inequalityYesRequired
MISRA04_13.613.6 Numeric variables being used within a for loop for iteration counting shall not be modified in the body of the loopYesRequired
MISRA04_14.114.1 There shall be no unreachable codeYesRequired
MISRA04_14.314.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 characterYesRequired
MISRA04_14.414.4 The goto statement shall not be usedYesRequired
MISRA04_14.514.5 The continue statement shall not be usedYesRequired
MISRA04_14.614.6 For any iteration statement there shall be at most one break statement used for loop terminationYesRequired
MISRA04_14.714.7 A function shall have a single point of exit at the end of the functionYesRequired
MISRA04_14.814.8 The statement forming the body of a switch, while, do ... while or for statement shall be a compound statementYesRequired
MISRA04_14.914.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 statementYesRequired
MISRA04_14.1014.10 All if ... else if constructs shall be terminated with an else clauseYesRequired
MISRA04_15.115.1 A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statementYesRequired
MISRA04_15.215.2 An unconditional break statement shall terminate every non-empty switch clauseYesRequired
MISRA04_15.315.3 The final clause of a switch statement shall be the default clauseYesRequired
MISRA04_15.515.5 Every switch statement shall have at least one case clauseYesRequired
MISRA04_16.116.1 Functions shall not be defined with variable numbers of arguments.YesRequired
MISRA04_16.216.2 Functions shall not call themselves, either directly or indirectly.YesRequired
MISRA04_16.316.3 All prototype parameters must have an identifier.YesRequired
MISRA04_16.416.4 use the same identifier in definition and declaration of functions.YesRequired
MISRA04_16.516.5 Functions with no parameters need explicit void keywordYesRequired
MISRA04_16.816.8 Always return a value in non-void functionsYesRequired
MISRA04_16.916.9 A function identifier shall only be used with either a preceding &, or with a parenthesised parameter list, which may be emptyYesRequired
MISRA04_17.317.3 >, >=, <, <= shall not be applied to objects of pointer type, except where they point to the same arrayYesRequired
MISRA04_17.517.5 No more than 2 levels of pointer indirectionYesAdvisory
MISRA04_17.617.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.YesRequired
MISRA04_18.418.4 Unions shall not be usedYesRequired
MISRA04_19.119.1 #include statements in a file should only be preceded by other preprocessor directives or commentsYesAdvisory
MISRA04_19.219.2 Non-standard characters should not occur in header file names in #include directivesYesAdvisory
MISRA04_19.319.3 The #include directive shall be followed by either a <filename> or "filename" sequenceYesRequired
MISRA04_19.519.5 Macros shall not be #define'd or #undef'd within a blockYesRequired
MISRA04_19.619.6 #undef shall not be usedYesRequired
MISRA04_19.719.7 A function should be used in preference to a function-like macroYesAdvisory
MISRA04_19.919.9 Arguments to a function-like macro shall not contain tokens that look like preprocessing directivesYesRequired
MISRA04_19.1019.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 ##YesRequired
MISRA04_19.1119.11 All macro identifiers in preprocessor directives shall be defined before use, except in #ifdef and #ifndef preprocessor directives and the defined() operatorNoRequired
MISRA04_19.1219.12 There shall be at most one occurrence of the # or ## operators in a single macro definitionYesRequired
MISRA04_19.1319.12 The # and ## operators should not be usedYesAdvisory
MISRA04_19.1419.14 The defined preprocessor operator shall only be used in one of the two standard formsYesRequired
MISRA04_19.1519.15 Precautions shall be taken in order to prevent the contents of a header file being included twiceYesRequired
MISRA04_19.1720.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 relatedYesRequired
MISRA04_20.120.1 Reserved identifiers, macros and functions in the standard library shall not be defined, redefined or undefinedYesRequired
MISRA04_20.220.2 The names of standard library macros and objects shall not be reusedYesRequired
MISRA04_20.420.4 Dynamic heap memory allocation shall not be usedYesRequired
MISRA04_20.520.5 The error indicator "errno" shall not be usedYesRequired
MISRA04_20.620.6 The macro offsetof, in library <stddef.h>, shall not be usedYesRequired
MISRA04_20.720.7 The setjmp macro and the longjmp function shall not be usedYesRequired
MISRA04_20.820.8 The signal handling facilities of <signal.h> shall not be usedYesRequired
MISRA04_20.920.9 The input output library <stdio.h> shall not be used in production codeYesRequired
MISRA04_20.1020.10 The library functions atof, atoi and atol from library <stdlib.h> shall not be usedYesRequired
MISRA04_20.1120.11 The library functions abort, exit, getenv and system from library <stdlib.h> shall not be usedYesRequired
MISRA04_20.1220.12 The time handling functions of library <time.h> shall not be usedYesRequired
MISRA04_21.121.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.YesRequired