0% found this document useful (0 votes)
689 views5 pages

Misra Rules

The document summarizes the MISRA C rules for using the C programming language in vehicle-based software. Some key rules include: only using characters and escape sequences defined in ISO C; restricting identifiers to 31 characters; declaring all variables before use; prohibiting implicit conversions that may lose information; and avoiding pointer arithmetic. The full rules are defined in the official MISRA guidelines document.

Uploaded by

sxqfjdpj
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
689 views5 pages

Misra Rules

The document summarizes the MISRA C rules for using the C programming language in vehicle-based software. Some key rules include: only using characters and escape sequences defined in ISO C; restricting identifiers to 31 characters; declaring all variables before use; prohibiting implicit conversions that may lose information; and avoiding pointer arithmetic. The full rules are defined in the official MISRA guidelines document.

Uploaded by

sxqfjdpj
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

MISRA C Rules

The following is a summary of the MISRA C rules. This document is not a definitive list these rules, which are only and completely defined in "MISRA Guidelines for the use of the C language in vehicle based software".

Environment
1 (req): 2 (adv): 3 (adv): All code shall conform to ISO 9899 standard, with no extensions permitted. Code written in languages other than C should only be used if there is a defined interface standard for object code to which the compiler/assembler for both languages conform Assembler language functions that are called from C should be written as C functions containing only in-line assembly language, and in-line assembly language should not be embedded in normal C code Provision should be made for appropriate run-time checking

4 (adv):

Character Sets
5 (req): 6 (req): 7 (req): 8 (req): Only those characters and escape sequences that are defined in the IOS C standard shall be used Values of character types shall be restricted to a defined and documented subset of ISO 10646-1 Tri-graphs shall not be used Multibyte characters and wide string literals shall not be used

Comments
9 (req): 10 (adv): Comments shall not be nested Sections of code should not be commented out

Identifiers
11 (req): Identifiers shall not rely on the significance of more than 31 characters. Compiler/linker shall check to ensure that 31 char significance and case sensitivity are supported for external identifiers Identifiers in different namespace shall not have the same spelling. Structure members are an exception

12 (adv):

Types
13 (adv): 14 (req): 15 (adv): 16 (req): 17 (req): The basic types char, int, short, long, double and float should not be used. Specific-length equivalents should be typedefd for the specific compiler, and these names used in the code The type char shall always be declared as unsigned char or signed char. See rule 13 Floating point implementations should comply with a defined floating point standard The underlying bit representation of floating point numbers shall not be used in any way by the programmer typedef names shall not be reused

Constants
18 (adv): 19 (req): Numeric constants should be suffixed to indicate type if possible Octal constants shall not be used Zero is okay

Declarations and Definitions


20 (req): 21 (req): 22 (adv): 23 (adv): 24 (req): 25 (req): 26 (req): 27 (adv): 28 (adv): 29 (req): All object and function identifiers shall be declared before use Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier Declaration of object should be at function scope unless a wider scope is necessary All declarations at file scope should be static if possible Identifiers shall not simultaneously have both internal and external linkage in the same translation unit An identifier with an external linkage shall have exactly one external definition If objects are declared more than once they shall have compatible declarations External objects should not be declared in more than one file The register storage class specifier should not be used The use of a tag shall agree with its declaration

Initialisation
30 (req): 31 (req): 32 (req): All automatic variables shall have a value assigned to them before use Braces shall be used to indicate and match the structure in the non-zero initialisation of arrays and structures In an enumerator list the = construct shall not be used to explicitly initialise members other than the fist unless it is used to initialise all items

Operators
33 (req): 34 (req): 35 (req): 36 (adv): 37 (req): 38 (req): 39 (req): 40 (adv): 41 (adv): 42 (req): The right hand operand of a && or || shall not contain side effects The operands of a logical && or || shall be primary expressions A single identifier, constant or parenthesised expression Assignment operators shall not be used in expressions that return Boolean values Logical operators shall not be confused with bitwise operators Bitwise operations shall not be performed on signed integer types The right hand operand of a shift operator shall lie between zero and one less the width in bits of the left hand operand The unary minus operator shall not be applied to an unsigned expression The sizeof operator should not be used on expressions that contain side effects The implementation of integer division in the chosen compiler should be determined, documented and taken into account The comma operator shall not be used, except in the control expression of a for loop

Conversions
43 (req): Implicit conversions that might result in a loss of information shall not be used

44 (adv): 45 (req):

Redundant explicit cast should not be used Type casting from any type to or from pointers shall not be used

Expressions
46 (req): 47 (adv): 48 (adv): 49 (adv): 50 (req): 51 (adv): The value of an expression shall be the same under any order of evaluation that the standard permits No dependence should be placed on Cs precedence rules Mixed precision arithmetic should use explicit casting to generate the desired result Tests of a value against zero should be explicit, unless the operant is effectively Boolean Floating point variables shall not be tested for exact inequality or inequality Evaluation of constant unsigned integer expression should not lead to wrap-around

Control Flow
52 (req): 53 (req): 54 (req): 55 (adv): 56 (req): 57 (req): 58 (req): 59 (req): 60 (adv): 61 (req): 62 (req): 63 (adv): 64 (req): 65 (req): 66 (adv): 67 (adv): There shall be no unreachable code All non-null statements shall have a side effect A null statement shall only appear on a line by its self, and shall not have any other text on the same line Label should not be used except in switch statements The goto statement shall not be used The continue statement shall not be used The break statement shall not be used, except to terminate the cases of a switch statement The statements forming the body of an if, else if, else, while, do while or for statement shall always be enclosed in braces All if, else if constructs should contain a final else clause Every non-empty case clause in a switch statement shall be terminated with a break statement All switch statements shall contain a final default clause A switch expression should not represent a Boolean value Every switch statement should have at least one case Floating point variables shall not be used as loop counters Only expression concerned with loop control should appear within a for statement Numeric variables being used within a for loop for iteration counting should not be modified in the body of the loop

Functions
68 (req): 69 (req): 70 (req): 71 (req): 72 (req): Functions shall always be declared at file scope Functions with a variable number of arguments shall not be used Functions shall not call themselves directly or indirectly Functions shall always have prototype declarations and the prototype shall be visible at both the function definition and call For each function parameter the type given and definition shall be identical, and the return type shall be identical

73 (req): 74 (req): 75 (req): 76 (req): 77 (req): 78 (req): 79 (req): 80 (req): 81 (adv): 82 (adv): 83 (req):

Identifiers shall either be given for all parameters in a prototype declaration, or none If identifiers are given for any parameters, then the identifiers used in declaration and definition shall be identical Every function shall have an explicit return type Functions with no parameter list shall be declared with parameter type void The unqualified type of parameters passed to a function shall be compatible with the unqualified expected types defined in the function prototype The number of parameters passed to a function shall match the function prototype The value returned by void functions shall not be used Void expressions shall not be passed as function parameters const qualification should be used on function parameters that are passed by reference, where it is intended that the function will not modify the parameter A function should have a single exit point For functions that do not have a void return type: i) ii) iii) There shall be one return statement for every exit branch (including the end of the program) Each return shall have an expression The return expression shall match the return type

84 (req): 85 (adv): 86 (adv):

For functions with void return type, return statements shall not have an expression Functions called with no parameters should have empty parentheses If a function returns error information then that information should be tested

Pre-Processing Directives
87 (req): 88 (req): 89 (req): 90 (req): 91 (req): 92 (adv): 93 (adv): 94 (req): 95 (req): 96 (req): 97 (adv): 98 (req): 99 (req): 100 (req): #include statements in a file shall only be preceded by other pre-processor directives or comments Non-standard characters shall not occur in header file names in #include directives The #include directive shall be followed by either a <filename> of "filename" sequence C macros shall only be used for symbolic constants, function like macros, type qualifiers and storage class specifiers Macros shall not be #define'd and #undef'd within a block #undef should not be used A function should be used in preference to a function-like macro A function-like macro shall not be 'called' without all of its arguments Arguments to a function-like macro shall not contain tokens that look like pre-processor directives In the definition of a function-like macro the whole definition, and each instance of a parameter, shall be enclosed in parenthesis Identifiers in pre-processor directives should be defined before use There shall be at most one occurrence of the # or ## pre-processor operators in a single macro definition All use of #pragma directive shall be documented and explained The defined pre-processor operator shall only be used in one of the two standard forms

Pointers and Arrays


101 (adv): Pointer arithmetic shall not be used 102 (adv): No more than 2 levels of pointer indirection should be used 103 (req): 104 (req): 105 (req): 106 (req): 107 (req): Relational operators shall not be applied to pointer types except where both operands are of the same type and point to the same array, structure or union Non-constant pointers to functions shall not be used All functions pointed to by a single pointer to a function shall be identical in the number and type of parameters and the return type The address of an object with automatic storage shall not be assigned to an object which may persist after the object has ceased to exist The null pointer shall not be dereferenced

Structures and Unions


108 (req): 109 (req): 110 (req): 111 (req): 112 (req): 113 (req): In the specification of a structure or union type, all members of the structure or union shall be fully specified Overlapping variable storage shall not be used Unions shall not be used to access the sub-parts of larger data types Bit fields shall only be defined to be one of type unsigned int or signed int Bit fields of type signed int shall be at least 2 bits long All members of a structure or union shall be named and shall only be access with their name

Standard Libraries
114 (req): 115 (req): 116 (req): Reserved words and the standard library function names shall not be redefined or undefined Standard library names shall not be reused All libraries used in production code shall be written to comply with the provisions of "MISRA Guidelines for the use of the C language in vehicle based software", and shall have been subject to appropriate validation The validity of values passed to library functions shall be checked Dynamic heap memory allocation shall not be used The error indicator errno shall not be used The macro offsetof, in library <stddef.h>, shall not be used <local.h> and the setlocale function shall not be used The setjmp macro and the longjmp function shall not be used The signal handling facilities of <signal.h> shall not be used The input/output library <stdio.h> shall not be used in production code The library functions atof, atoi and atol from library <stslib.h> shall not be used The library functions abort, exit, getenv and system from library <stdlib.h> shall not be used The time handling functions of library <time.h> shall not be used

117 (req): 118 (req): 119 (req): 120 (req): 121 (req): 122 (req): 123 (req): 124 (req): 125 (req): 126 (req): 127 (req):

You might also like