# Misra C++ 2008 规范 # Misra Cpp 2008 ---- ## Language independent issues ### Unnecessary constructs Rule 0-1-1 (Required) A project shall not contain unreachable code. Rule 0-1-2 (Required) A project shall not contain infeasible paths. Rule 0-1-3 (Required) A project shall not contain unused variables. Rule 0-1-4 (Required) A project shall not contain non-volatile POD variables having only one use. Rule 0-1-5 (Required) A project shall not contain unused type declarations. Rule 0-1-6 (Required) A project shall not contain instances of non- volatile variables being given values that are never subsequently used. Rule 0-1-7 (Required) The value returned by a function having a non-void return type that is not an overloaded operator shall always be used. Rule 0-1-8 (Required) All functions with void return type shall have external side effect(s). Rule 0-1-9 (Required) There shall be no dead code. Rule 0-1-10 (Required) Every defined function shall be called at least once. Rule 0-1-11 (Required) There shall be no unused parameters (named or unnamed) in non-virtual functions. Rule 0-1-12 (Required) There shall be no unused parameters (named or unnamed) in the set of parameters for a virtual function and all the functions that override it. ### Storage Rule 0-2-1 (Required) An object shall not be assigned to an overlapping object. ### Runtime failures Rule 0-3-1 (Document) Minimization of run-time failures shall be ensured by the use of at least one of: 1. static analysis tools/techniques; 2. dynamic analysis tools/techniques; 3. explicit coding of checks to handle run-time faults. Rule 0-3-2 (Required) If a function generates error information, then that error information shall be tested. ### Arithmetic Rule 0-4-1 (Document) Use of scaled-integer or fixed-point arithmetic shall be documented. Rule 0-4-2 (Document) Use of floating-point arithmetic shall be documented. Rule 0-4-3 (Document) Floating-point implementations shall comply with a defined floating-point standard. ---- ## General ### Language Rule 1-0-1 (Required) All code shall conform to ISO/IEC 14882:2003 "The C++ Standard Incorporating Technical Corrigendum 1". Rule 1-0-2 (Required) Multiple compilers shall only be used if they have a common, defined interface. Rule 1-0-3 (Document) The implementation of integer division in the chosen compiler shall be determined and documented. ---- ## Lexical conventions ### Character sets Rule 2-2-1 (Document) The character set and the corresponding encoding shall be documented. ### Trigraph sequences Rule 2-3-1 (Required) Trigraphs shall not be used. ### Alternative tokens Rule 2-5-1 (Advisory) Digraphs should not be used. ### Comments Rule 2-7-1 (Required) The character sequence /* shall not be used within a C-style comment. Rule 2-7-2 (Required) Sections of code shall not be "commented out" using C-style comments. Rule 2-7-3 (Advisory) Sections of code should not be "commented out" using C++ comments. ### Identifiers Rule 2-10-1 (Required) Different identifiers shall be typographically unambiguous. Rule 2-10-2 (Required) Identifiers declared in an inner scope shall not hide an identifier declared in an outer scope. Rule 2-10-3 (Required) A typedef name (including qualification, if any) shall be a unique identifier. Rule 2-10-4 (Required) A class, union or enum name (including qualification, if any) shall be a unique identifier. Rule 2-10-5 (Required) The identifier name of a non-member object or function with static storage duration should not be reused. Rule 2-10-6 (Required) If an identifier refers to a type, it shall not also refer to an object or a function in the same scope. ### Literals Rule 2-13-1 (Required) Only those escape sequences that are defined in ISO/IEC 14882:2003 shall be used. Rule 2-13-2 (Required) Octal constants (other than zero) and octal escape sequences (other than "\0") shall not be used. Rule 2-13-3 (Required) A "U " suffix shall be applied to all octal or hexadecimal integer literals of unsigned type. Rule 2-13-4 (Required) Literal suffixes shall be upper case. Rule 2-13-5 (Required) Narrow and wide string literals shall not be concatenated. ---- ## Basic concepts ### Declarations and definitions Rule 3-1-1 (Required) It shall be possible to include any header file in multiple translation units without violating the One Definition Rule. Rule 3-1-2 (Required) Functions shall not be declared at block scope. Rule 3-1-3 (Required) When an array is declared, its size shall either be stated explicitly or defined implicitly by initialization. ### One Definition Rule Rule 3-2-1 (Required) All declarations of an object or function shall have compatible types. Rule 3-2-2 (Required) The One Definition Rule shall not be violated. Rule 3-2-3 (Required) A type, object or function that is used in multiple translation units shall be declared in one and only one file. Rule 3-2-4 (Required) An identifier with external linkage shall have exactly one definition. ### Declarative regions and scope Rule 3-3-1 (Required) Objects or functions with external linkage shall be declared in a header file. Rule 3-3-2 (Required) If a function has internal linkage then all re-declarations shall include the static storage class specifier. ### Name lookup Rule 3-4-1 (Required) An identifier declared to be an object or type shall be defined in a block that minimizes its visibility. ### Types Rule 3-9-1 (Required) The types used for an object, a function return type, or a function parameter shall be token-for-token identical in all declarations and re-declarations. Rule 3-9-2 (Advisory) typedefs that indicate size and signedness should be used in place of the basic numerical types. Rule 3-9-3 (Required) The underlying bit representations of floating-point values shall not be used. ---- ## Standard conversions ### Integral promotions Rule 4-5-1 (Required) Expressions with type bool shall not be used as operands to built-in operators other than the assignment operator =, the logical operators &&, ||, !, the equality operators == and !=, the unary & operator, and the conditional operator. Rule 4-5-2 (Required) Expressions with type enum shall not be used as operands to built-in operators other than the subscript operator [ ], the assignment operator =, the equality operators == and !=, the unary & operator, and the relational operators <, <=, >, >=. Rule 4-5-3 (Required) Expressions with type (plain) char and wchar_t shall not be used as operands to built-in operators other than the assignment operator =, the equality operators == and !=, and the unary & operator. ### Pointer conversions Rule 4-10-1 (Required) NULL shall not be used as an integer value. Rule 4-10-2 (Required) Literal zero (0) shall not be used as the null-pointer-constant. ---- ## Expressions ### Primary expressions Rule 5-0-1 (Required) The value of an expression shall be the same under any order of evaluation that the standard permits. Rule 5-0-2 (Advisory) Limited dependence should be placed on C++ operator precedence rules in expressions. Rule 5-0-3 (Required) A cvalue expression shall not be implicitly converted to a different underlying type. Rule 5-0-4 (Required) An implicit integral conversion shall not change the signedness of the underlying type. Rule 5-0-5 (Required) There shall be no implicit floating-integral conversions. Rule 5-0-6 (Required) An implicit integral or floating-point conversion shall not reduce the size of the underlying type. Rule 5-0-7 (Required) There shall be no explicit floating-integral conversions of a cvalue expression. Rule 5-0-8 (Required) An explicit integral or floating-point conversion shall not increase the size of the underlying type of a cvalue expression. Rule 5-0-9 (Required) An explicit integral conversion shall not change the signedness of the underlying type of a cvalue expression. Rule 5-0-10 (Required) 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 operand. Rule 5-0-11 (Required) The plain char type shall only be used for the storage and use of character values. Rule 5-0-12 (Required) Signed char and unsigned char type shall only be used for the storage and use of numeric values. Rule 5-0-13 (Required) The condition of an if-statement and the condition of an iteration-statement shall have type bool. Rule 5-0-14 (Required) The first operand of a conditional-operator shall have type bool. Rule 5-0-15 (Required) Array indexing shall be the only form of pointer arithmetic. Rule 5-0-16 (Required) A pointer operand and any pointer resulting from pointer arithmetic using that operand shall both address elements of the same array. Rule 5-0-17 (Required) Subtraction between pointers shall only be applied to pointers that address elements of the same array. Rule 5-0-18 (Required) >, >=, <, <= shall not be applied to objects of pointer type, except where they point to the same array. Rule 5-0-19 (Required) The declaration of objects shall contain no more than two levels of pointer indirection. Rule 5-0-20 (Required) Non-constant operands to a binary bitwise operator shall have the same underlying type. Rule 5-0-21 (Required) Bitwise operators shall only be applied to operands of unsigned underlying type. ### Postfix expressions Rule 5-2-1 (Required) Each operand of a logical && or || shall be a postfix-expression. Rule 5-2-2 (Required) A pointer to a virtual base class shall only be cast to a pointer to a derived class by means of dynamic_cast. Rule 5-2-3 (Advisory) Casts from a base class to a derived class should not be performed on polymorphic types. Rule 5-2-4 (Required) C-style casts (other than void casts) and functional notation casts (other than explicit constructor calls) shall not be used. Rule 5-2-5 (Required) A cast shall not remove any const or volatile qualification from the type of a pointer or reference. Rule 5-2-6 (Required) A cast shall not convert a pointer to a function to any other pointer type, including a pointer to function type. Rule 5-2-7 (Required) An object with pointer type shall not be converted to an unrelated pointer type, either directly or indirectly. Rule 5-2-8 (Required) An object with integer type or pointer to void type shall not be converted to an object with pointer type. Rule 5-2-9 (Advisory) A cast should not convert a pointer type to an integral type. Rule 5-2-10 (Advisory) The increment (++) and decrement (--) operators should not be mixed with other operators in an expression. Rule 5-2-11 (Required) The comma operator, && operator and the || operator shall not be overloaded. Rule 5-2-12 (Required) An identifier with array type passed as a function argument shall not decay to a pointer. ### Unary expressions Rule 5-3-1 (Required) Each operand of the ! operator, the logical && or the logical || operators shall have type bool. Rule 5-3-2 (Required) The unary minus operator shall not be applied to an expression whose underlying type is unsigned. Rule 5-3-3 (Required) The unary & operator shall not be overloaded. Rule 5-3-4 (Required) Evaluation of the operand to the sizeof operator shall not contain side effects. ### Shift operators Rule 5-8-1 (Required) 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. ### Logical AND operator Rule 5-14-1 (Required) The right hand operand of a logical && or || operator shall not contain side effects. ### Assignment operators Rule 5-17-1 (Required) The semantic equivalence between a binary operator and its assignment operator form shall be preserved. ### Comma operator Rule 5-18-1 (Required) The comma operator shall not be used. ### Constant expressions Rule 5-19-1 (Advisory) Evaluation of constant unsigned integer expressions should not lead to wrap-around. ---- ## Statements ### Expression statement Rule 6-2-1 (Required) Assignment operators shall not be used in sub-expressions. Rule 6-2-2 (Required) Floating-point expressions shall not be directly or indirectly tested for equality or inequality. Rule 6-2-3 (Required) 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 character. ### Compound statement Rule 6-3-1 (Required) The statement forming the body of a switch, while, do ... while or for statement shall be a compound statement. ### Selection statements Rule 6-4-1 (Required) An if ( condition ) construct shall be followed by a compound statement. The else keyword shall be followed by either a compound statement, or another if statement. Rule 6-4-2 (Required) All if - else if constructs shall be terminated with an else clause. Rule 6-4-3 (Required) A switch statement shall be a well-formed switch statement. Rule 6-4-4 (Required) A switch-label shall only be used when the most closely-enclosing compound statement is the body of a switch statement. Rule 6-4-5 (Required) An unconditional throw or break statement shall terminate every non-empty switch-clause. Rule 6-4-6 (Required) The final clause of a switch statement shall be the default-clause. Rule 6-4-7 (Required) The condition of a switch statement shall not have bool type. Rule 6-4-8 (Required) Every switch statement shall have at least one case-clause. ---- ## Iteration statements ### The for statement Rule 6-5-1 (Required) A for loop shall contain a single loop-counter which shall not have floating type. Rule 6-5-2 (Required) If loop-counter is not modified by -- or ++, then, within condition, the loop-counter shall only be used as an operand to <=, <, > or >=. Rule 6-5-3 (Required) The loop-counter shall not be modified within condition or statement. Rule 6-5-4 (Required) The loop-counter shall be modified by one of: --, ++, -=n, or +=n; where n remains constant for the duration of the loop. Rule 6-5-5 (Required) A loop-control-variable other than the loop-counter shall not be modified within condition or expression. Rule 6-5-6 (Required) A loop-control-variable other than the loop-counter which is modified in statement shall have type bool. ### Jump statements Rule 6-6-1 (Required) Any label referenced by a goto statement shall be declared in the same block, or in a block enclosing the goto statement. Rule 6-6-2 (Required) The goto statement shall jump to a label declared later in the same function body. Rule 6-6-3 (Required) The continue statement shall only be used within a well-formed for loop. Rule 6-6-4 (Required) For any iteration statement there shall be no more than one break or goto statement used for loop termination. Rule 6-6-5 (Required) A function shall have a single point of exit at the end of the function. ---- ## Declarations ### Specifiers Rule 7-1-1 (Required) A variable which is not modified shall be const qualified. Rule 7-1-2 (Required) A pointer or reference parameter in a function shall be declared as pointer to const or reference to const if the corresponding object is not modified. Rule 7-1-3 (Required) An expression with enum underlying type shall only have values corresponding to the enumerators of the enumeration. ### Enumeration declarations Rule 7-2-1 (Required) An expression with enum underlying type shall only have values corresponding to the enumerators of the enumeration. ### Namespaces Rule 7-3-1 (Required) The global namespace shall only contain main, namespace declarations and extern "C" declarations. Rule 7-3-2 (Required) The identifier main shall not be used for a function other than the global function main. Rule 7-3-3 (Required) There shall be no unnamed namespaces in header files. Rule 7-3-4 (Required) Using-directives shall not be used. Rule 7-3-5 (Required) Multiple declarations for an identifier in the same namespace shall not straddle a using-declaration for that identifier. Rule 7-3-6 (Required) Using-directives and using-declarations (excluding class scope or function scope using-declarations) shall not be used in header files. ### The asm declaration Rule 7-4-1 (Document) All usage of assembler shall be documented. Rule 7-4-2 (Required) Assembler instructions shall only be introduced using the asm declaration. Rule 7-4-3 (Required) Assembly language shall be encapsulated and isolated. ### Linkage specifications Rule 7-5-1 (Required) A function shall not return a reference or a pointer to an automatic variable (including parameters), defined within the function. Rule 7-5-2 (Required) 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. Rule 7-5-3 (Required) A function shall not return a reference or a pointer to a parameter that is passed by reference or const reference. Rule 7-5-4 (Advisory) Functions should not call themselves, either directly or indirectly. ---- ## Declarators ### General Rule 8-0-1 (Required) An init-declarator-list or a member-declarator-list shall consist of a single init-declarator or member-declarator respectively. ### Meaning of declarators Rule 8-3-1 (Required) Parameters in an overriding virtual function shall either use the same default arguments as the function they override, or else shall not specify any default arguments. ### Function definitions Rule 8-4-1 (Required) Functions shall not be defined using the ellipsis notation. Rule 8-4-2 (Required) The identifiers used for the parameters in a re-declaration of a function shall be identical to those in the declaration. Rule 8-4-3 (Required) All exit paths from a function with non-void return type shall have an explicit return statement with an expression. Rule 8-4-4 (Required) A function identifier shall either be used to call the function or it shall be preceded by &. ### Initializers Rule 8-5-1 (Required) All variables shall have a defined value before they are used. Rule 8-5-2 (Required) Braces shall be used to indicate and match the structure in the non-zero initialization of arrays and structures. Rule 8-5-3 (Required) In an enumerator list, the = construct shall not be used to explicitly initialize members other than the first, unless all items are explicitly initialized. ---- ## Classes ### Member functions Rule 9-3-1 (Required) Const member functions shall not return non-const pointers or references to class-data. Rule 9-3-2 (Required) Member functions shall not return non-const handles to class-data. Rule 9-3-3 (Required) If a member function can be made static then it shall be made static, otherwise if it can be made const then it shall be made const. ### Unions Rule 9-5-1 (Required) Unions shall not be used. ### Bit-fields Rule 9-6-1 (Required) When the absolute positioning of bits representing a bit-field is required, then the behaviour and packing of bit-fields shall be documented. Rule 9-6-2 (Required) Bit-fields shall be either bool type or an explicitly unsigned or signed integral type. Rule 9-6-3 (Required) Bit-fields shall not have enum type. Rule 9-6-4 (Required) Named bit-fields with signed integer type shall have a length of more than one bit. ---- ## Derived classes ### Multiple base classes Rule 10-1-1 (Advisory) Classes should not be derived from virtual bases. Rule 10-1-2 (Required) A base class shall only be declared virtual if it is used in a diamond hierarchy. Rule 10-1-3 (Required) An accessible base class shall not be both virtual and non-virtual in the same hierarchy. ### Member name lookup Rule 10-2-1 (Advisory) All accessible entity names within a multiple inheritance hierarchy should be unique. ### Virtual functions Rule 10-3-1 (Required) There shall be no more than one definition of each virtual function on each path through the inheritance hierarchy. Rule 10-3-2 (Required) Each overriding virtual function shall be declared with the virtual keyword. Rule 10-3-3 (Required) A virtual function shall only be overridden by a pure virtual function if it is itself declared as pure virtual. ---- ## Member access control ### General Rule 11-0-1 (Required) Member data in non-POD class types shall be private. ---- ## Special member functions ### Constructors Rule 12-1-1 (Required) An object-s dynamic type shall not be used from the body of its constructor or destructor. Rule 12-1-2 (Advisory) All constructors of a class should explicitly call a constructor for all of its immediate base classes and all virtual base classes. Rule 12-1-3 (Required) All constructors that are callable with a single argument of fundamental type shall be declared explicit. ### Copying class objects Rule 12-8-1 (Required) A copy constructor shall only initialize its base classes and the non-static members of the class of which it is a member. Rule 12-8-2 (Required) The copy assignment operator shall be declared protected or private in an abstract class. ---- ## Templates ### Template declarations Rule 14-5-1 (Required) A non-member generic function shall only be declared in a namespace that is not an associated namespace. Rule 14-5-2 (Required) A copy constructor shall be declared when there is a template constructor with a single parameter that is a generic parameter. Rule 14-5-3 (Required) A copy assignment operator shall be declared when there is a template assignment operator with a parameter that is a generic parameter. ### Name resolution Rule 14-6-1 (Required) In a class template with a dependent base, any name that may be found in that dependent base shall be referred to using a qualified-id or this-> Rule 14-6-2 (Required) The function chosen by overload resolution shall resolve to a function declared previously in the translation unit. ### Template instantiation and specialization Rule 14-7-1 (Required) All class templates, function templates, class template member functions and class template static members shall be instantiated at least once. Rule 14-7-2 (Required) For any given template specialization, an explicit instantiation of the template with the template- arguments used in the specialization shall not render the program ill-formed. Rule 14-7-3 (Required) All partial and explicit specializations for a template shall be declared in the same file as the declaration of their primary template. ### Function template specialization Rule 14-8-1 (Required) Overloaded function templates shall not be explicitly specialized. Rule 14-8-2 (Advisory) The viable function set for a function call should either contain no function specializations, or only contain function specializations. ---- ## Exception handling ### General Rule 15-0-1 (Document) Exceptions shall only be used for error handling. Rule 15-0-2 (Advisory) An exception object should not have pointer type. Rule 15-0-3 (Required) Control shall not be transferred into a try or catch block using a goto or a switch statement. ### Throwing an exception Rule 15-1-1 (Required) The assignment-expression of a throw statement shall not itself cause an exception to be thrown. Rule 15-1-2 (Required) NULL shall not be thrown explicitly. Rule 15-1-3 (Required) An empty throw (throw;) shall only be used in the compound-statement of a catch handler. ### Handling an exception Rule 15-3-1 (Required) Exceptions shall be raised only after start-up and before termination of the program. Rule 15-3-2 (Advisory) There should be at least one exception handler to catch all otherwise unhandled exceptions Rule 15-3-3 (Required) Handlers of a function-try-block implementation of a class constructor or destructor shall not reference non- static members from this class or its bases. Rule 15-3-4 (Required) Each exception explicitly thrown in the code shall have a handler of a compatible type in all call paths that could lead to that point. Rule 15-3-5 (Required) A class type exception shall always be caught by reference. Rule 15-3-6 (Required) Where multiple handlers are provided in a single try-catch statement or function-try-block for a derived class and some or all of its bases, the handlers shall be ordered most-derived to base class. Rule 15-3-7 (Required) Where multiple handlers are provided in a single try-catch statement or function-try-block, any ellipsis (catch-all) handler shall occur last. ### Exception specifications Rule 15-4-1 (Required) If a function is declared with an exception-specification, then all declarations of the same function (in other translation units) shall be declared with the same set of type-ids. ### Special functions Rule 15-5-1 (Required) A class destructor shall not exit with an exception. Rule 15-5-2 (Required) Where a function-s declaration includes an exception- specification, the function shall only be capable of throwing exceptions of the indicated type(s). Rule 15-5-3 (Required) The terminate() function shall not be called implicitly. ---- ## Preprocessing directives ### General Rule 16-0-1 (Required) #include directives in a file shall only be preceded by other preprocessor directives or comments. Rule 16-0-2 (Required) Macros shall only be #define-d or #undef-d in the global namespace. Rule 16-0-3 (Required) #undef shall not be used. Rule 16-0-4 (Required) Function-like macros shall not be defined. Rule 16-0-5 (Required) Arguments to a function-like macro shall not contain tokens that look like preprocessing directives. Rule 16-0-6 (Required) 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 ##. Rule 16-0-7 (Required) Undefined macro identifiers shall not be used in #if or #elif preprocessor directives, except as operands to the defined operator. Rule 16-0-8 (Required) If the # token appears as the first token on a line, then it shall be immediately followed by a preprocessing token. ### Conditional inclusion Rule 16-1-1 (Required) The defined preprocessor operator shall only be used in one of the two standard forms. Rule 16-1-2 (Required) All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if or #ifdef directive to which they are related. ### Source file inclusion Rule 16-2-1 (Required) The pre-processor shall only be used for file inclusion and include guards. Rule 16-2-2 (Required) C++ macros shall only be used for include guards, type qualifiers, or storage class specifiers. Rule 16-2-3 (Required) Include guards shall be provided. Rule 16-2-4 (Required) The ', ", /* or // characters shall not occur in a header file name. Rule 16-2-5 (Advisory) The \ character should not occur in a header file name. Rule 16-2-6 (Required) The #include directive shall be followed by either a or "filename" sequence. ### Macro replacement Rule 16-3-1 (Required) There shall be at most one occurrence of the # or ## operators in a single macro definition. Rule 16-3-2 (Advisory) The # and ## operators should not be used. ### Pragma directive Rule 16-6-1 (Document) All uses of the #pragma directive shall be documented. ---- ## Library introduction ### General Rule 17-0-1 (Required) Reserved identifiers, macros and functions in the standard library shall not be defined, redefined or undefined. Rule 17-0-2 (Required) The names of standard library macros and objects shall not be reused. Rule 17-0-3 (Required) The names of standard library functions shall not be overridden. Rule 17-0-4 (Document) All library code shall conform to MISRA C++. Rule 17-0-5 (Document) The setjmp macro and the longjmp function shall not be used. ---- ## Language support library ### General Rule 18-0-1 (Required) The C library shall not be used. Rule 18-0-2 (Required) The library functions atof, atoi and atol from library shall not be used. Rule 18-0-3 (Required) The library functions abort, exit, getenv and system from library shall not be used. Rule 18-0-4 (Required) The time handling functions of library shall not be used. Rule 18-0-5 (Required) The unbounded functions of library shall not be used. ### Implementation properties Rule 18-2-1 (Required) The macro offsetof shall not be used. ### Dynamic memory management Rule 18-4-1 (Required) Dynamic heap memory allocation shall not be used. ### Other runtime support Rule 18-7-1 (Required) The signal handling facilities of shall not be used. ---- ## Diagnostics library ### Error numbers Rule 19-3-1 (Required) The error indicator errno shall not be used. ---- ## Input/output library ### General Rule 27-0-1 (Required) The stream input/output library shall not be used. ----