MISRA 2004

Below are the list of MISRA 2004 rules supported by Embold:

Rules	Description
Rule 2.3	The character sequence /* shall NOt be used within a comment.
Rule 2.4	Sections of code should NOt be “commented out”.
Rule 4.2	Trigraphs shall NOt be used.
Rule 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.
Rule 5.3	A typedef name shall be a unique identifier.
Rule 5.4	A tag name shall be a unique identifier.
Rule 5.7	NO identifier name should be reused.
Rule 6.4	Bit fields shall only be defined to be of type unsigned int or signed int.
Rule 6.5	Bit fields of signed type shall be at least 2 bits long.
Rule 7.1	Octal constants (other than zero) and octal escape sequences shall NOt be used.
Rule 8.2	Whenever an object or function is declared or defined, its type shall be explicitly stated.
Rule 8.7	Objects shall be defined at block scope if they are only accessed from within a single function.
Rule 8.8	An external object or function shall be declared in one and only one file.
Rule 8.9	An identifier with external linkage shall have exactly one external definition.
Rule 8.11	The static storage class specifier shall be used in definitions and declarations of objects and functions that have internal linkage.
Rule 8.12	When an array is declared with external linkage, its size shall be state explicitly or defined implicitly by initialisation.
Rule 9.1	All automatic variables shall have been assigned a value before being used.
Rule 9.2	Braces shall be used to indicate and match the structure in the NOn-zero initialisation of arrays and structures.
Rule 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.
Rule 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) 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.
Rule 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.
Rule 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.
Rule 10.6	A “U” suffix shall be applied to all constants of unsigned type.
Rule 11.1	Conversions shall NOt be performed between a pointer to a function and any type other than an integral type.
Rule 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
Rule 11.3	A cast should NOt be performed between a pointer type and an integral type.
Rule 11.4	A cast should NOt be performed between a pointer to object type and a different pointer to object type.
Rule 11.5	A cast shall NOt be performed that removes any const or volatile qualification from the type addressed by a pointer.
Rule 12.1	Limited dependence should be placed on C’s operator precedence rules in expressions.
Rule 12.2	The value of an expression shall be the same under any order of evaluation that the standard permits.
Rule 12.4	The right-hand operand of a logical && or \|\| operator shall NOt contain side effects.
Rule 12.7	Bitwise operators shall NOt be applied to operands whose underlying type is signed.
Rule 12.10	The comma operator shall NOt be used.
Rule 12.11	Evaluation of constant unsigned integer expressions should NOt lead to wrap-around.
Rule 13.4	The controlling expression of a for statement shall NOt contain any objects of floating type.
Rule 14.1	There shall be NO unreachable code.
Rule 14.4	The goto statement shall NOt be used.
Rule 14.6	For any iteration statement there shall be at most one break statement used for loop termination.
Rule 14.7	A function shall have a single point of exit at the end of the function.
Rule 14.8	The statement forming the body of a switch, while, do ... while or for statement shall be a compound statement.
Rule 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.
Rule 14.10	All if ... else if constructs shall be terminated with an else clause.
Rule 15.0	The MISRA C switch syntax shall be used
Rule 15.1	A switch label shall only be used when the most closely- enclosing compound statement is the body of a switch statement.
Rule 15.2	An unconditional break statement shall terminate every NOn- empty switch clause.
Rule 15.3	The final clause of a switch statement shall be the default clause.
Rule 15.4	A switch expression shall NOt represent a value that is effectively Boolean.
Rule 15.5	Every switch statement shall have at least one case clause.
Rule 16.1	Functions shall NOt be defined with a variable number of arguments.
Rule 16.2	Functions shall NOt call themselves, either directly or indirectly.
Rule 16.3	Identifiers shall be given for all of the parameters in a function prototype declaration.
Rule 16.4	The identifiers used in the declaration and definition of a function shall be identical.
Rule 16.6	The number of arguments passed to a function shall match the number of parameters.
Rule 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.
Rule 16.8	All exit paths from a function with NOn-void return type shall have an explicit return statement with an expression.
Rule 17.2	Pointer subtraction shall only be applied to pointers that address elements of the same array.
Rule 17.3	>, >=, <, <= shall NOt be applied to pointer types except where they point to the same array
Rule 18.2	An object shall NOt be assigned to an overlapping object.
Rule 18.4	Unions shall NOt be used.
Rule 19.1	#include statements in a file should only be preceded by other preprocessor directives or comments.
Rule 19.2	NOn-standard characters should NOt occur in header file names in #include directives.
Rule 19.3	The #include directive shall be followed by either a or ″filename″ sequence.
Rule 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-while-zero construct.
Rule 19.5	Macros shall NOt be #define’d or #undef’d within a block.
Rule 19.6	#undef shall NOt be used.
Rule 19.7	A function should be used in preference to a function-like macro.
Rule 19.12	There shall be at most one occurrence of the # or ## operators in a single macro definition.
Rule 19.13	The # and ## operators should NOt be used.
Rule 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.
Rule 20.1	Reserved identifiers, macros and functions in the standard library, shall NOt be defined, redefined or undefined.
Rule 20.2	The names of standard library macros, objects and functions shall NOt be reused.
Rule 20.5	The error indicator errNO shall NOt be used.
Rule 20.7	The setjmp macro and the longjmp function shall NOt be used.
Rule 20.8	The signal handling facilities of shall NOt be used
Rule 20.9	The input/output library shall NOt be used in production code.
Rule 20.10	The library functions atof, atoi and atol from library shall NOt be used.
Rule 20.11	The library functions abort, exit, getenv and system from library shall NOt be used.
Rule 20.12	The time handling functions of library shall NOt be used.