Try Scanyp for Free
Start Free Trial
Misra C 2012

Misra C 2012 Standards

Introduction

MISRA is a collaboration between manufacturers, component suppliers and engineering consultancies which seeks to promote best practice in developing safety- and security-related electronic systems and other software-intensive applications.

To learn Misra C Standards, you can print this MISRA C:2012 Amendment 2 pdf

99 Queries in Misra C standards

6 Uncessary Constructs, 2 Comments, 5 Identifiers and Lexical Conventions, 7 Declarations and defintions, 5 Pointer type conversions, 16 Expressions, 15 Statements, 9 Declarations, 6 Declarators, 7 Classes, 5 Exceptions, 4 Preprocessor, 12 Library.

Uncessary Constructs

  • Rule 2.1: A project shall not contains unreachable code: Code is unreachable if there is no syntactic (controlflow) path to it. If such code exists, it is unclear if this is intentional or simply that an appropriate path has been accidentally omitted. Compilers may choose not to generate code for these constructs, meaning that, even if the unreachable code is intentional, it may not be present in the final executable code.

    This coding standard is computed with the following query:

    warnif count > 0         
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_unreachable" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 2.2: There shall be no dead code:

    This coding standard is computed with the following query:

    warnif count > 0         
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_unreachable" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 2.3: A project shall not contains unused typedef declarations: If a type is declared but not used, then it is unclear to a reviewer if the type is redundant or it has been left unused by mistake.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_unused_local_typedef" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 2.5: A project should not contain unused macro declarations: If a macro is declared but not used, then it is unclear to a reviewer if the macro is redundant or it hasbeen left unused by mistake.

    This coding standard is computed with the following query:

    warnif count > 0         
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="pp_macro_not_used" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 2.6: A function should not contain unused label declarations: If a label is declared but not used, then it is unclear to a reviewer if the label is redundant or it hasbeen left unused by mistake.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_unused_label" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 2.7: There shall be no unused parameters in functions: Unused function parameters are often due to design changes and can lead to mismatched parameter lists.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues 
    where issue.ToolName=="Clang" && issue.Type=="warn_unused_parameter"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

Comments

  • Rule 3.1: The character sequences /* and // shall not be used within a comment: If a comment starting sequence, /* or // , occurs within a /* comment, is it quite likely to be causedby a missing*/ comment ending sequence.rule.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_nested_block_comment" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 3.2: Line-splicing shall not be used in // comments: Line-splicing occurs when the \ character is immediately followed by a new-line character. If the source file contains multibyte characters, they are converted to the source character set before anysplicing occurs.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="ext_multi_line_line_comment" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

Identifiers and Lexical Conventions

  • Rule 4.2: Trigraphs shall not be used: Trigraphs are denoted by a sequence of 2 question marksfollowed by a specified third character(e.g. ??- represents a “~” (tilde) character and ??) represents a “]”). They can cause accidental confusion with other uses of two question marks.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="trigraph_ignored" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5.3: Identifiers declared in a inner scope shall not hide an ientifier declared in out of dcope: // If an identifier is declared in an inner scope and it uses the same name as an identifier that already exists in an outer scope, // then the innermost declaration will “hide” the outer one. This may lead to developer confusion.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_decl_shadow" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 5.7: A tag name shall be a unique identifier:

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="err_use_with_wrong_tag" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 7.2: A U suffix shall be applied to all octal or hexadecimal integer literals of unsigned type: The type of an integer is dependent on a complex combination of factors including: The magnitude of the constant; The implemented sizes of the integer types; The presence of any suffixes; The number base in which the value is expressed (i.e. decimal, octal or hexadecimal).

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where  issue.Type=="Rule2-13-3" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 7.3: Literal suffixes shall be upper case: Using upper case literal suffixes removes the potential ambiguity between “1”(digit1) and “l” (letter el) for declaring literals.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where  issue.Type=="Rule2-13-4" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

Declarations and defintions

  • Rule 8.1: Types shall be explicitly specified: Trigraphs are denoted by a sequence of 2 question marksfollowed by a specified third character(e.g. ??- represents a “~” (tilde) character and ??) represents a “]”). They can cause accidental confusion with other uses of two question marks.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="trigraph_ignored" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 8.4:A compatible declaration shall be visible when an object or functionwith external linkage is defined: Trigraphs are denoted by a sequence of 2 question marksfollowed by a specified third character(e.g. ??- represents a “~” (tilde) character and ??) represents a “]”). They can cause accidental confusion with other uses of two question marks.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="trigraph_ignored" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 8.11: When an array is declared, its size shall either be stated explicitly or defined implicitily by initialization: Although it is possible to declare an array of incomplete type and access its elements, it is safer to do so when the size of the array can be explicitly determined.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule3-1-3"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 8.12: Within an enumerator list, the value of an implicitly-specifiedenumeration constant shall be unique: // Although it is possible to declare an array of incomplete type and access its elements, // it is safer to do so when the size of the array can be explicitly determined.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule3-1-3"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 9.1: The value of an object with automatic storage duration shall not beread before it has been set: The intent of this rule is that all variables shall have been written to before they are read. This does not necessarily require initialization at declaration.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_uninit_var" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 9.2: The initializer for an aggregate or union shall be enclosed in braces: The intent of this rule is that all variables shall have been written to before they are read. This does not necessarily require initialization at declaration.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_uninit_var" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 9.4: An element of an object shall not be initialized more than once: The intent of this rule is that all variables shall have been written to before they are read. This does not necessarily require initialization at declaration.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_uninit_var" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

Pointer type conversions

  • Rule 11.1: Conversions shall not be performed between a pointer to a functionand any other type: Header files should be used to declare objects, functions, inline functions, function templates, typedefs,macros,classes, and class templates and shall not contain or produce definitions of objects or functions (or fragment of functions or objects) that occupy storage.

    This coding standard is computed with the following query:

    warnif count > 0 
    from m in JustMyCode.Methods where m.NbLinesOfCode>0 
    && m.SourceDecls.First().SourceFile.FileNameExtension.StartsWith("h")
    select new { m,IncludeFile=m.SourceDecls.First().SourceFile.FilePathString }

  • Rule 11.5: A conversion should not be performed from pointer to void into pointer to object: A function declared at block scope will refer to a member of the enclosing namespace, and so the declaration should be explicitly placed at the namespace level. Additionally, where a declaration statement could either declare a function or an object, the compiler will choose to declare the function. To avoid potential developer confusion over the meaning of a declaration, functions should not be declared at block scope.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule3-1-2"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 11.7: A cast shall not be performed between pointer to object and a non-integer arithmetic type: Although it is possible to declare an array of incomplete type and access its elements, it is safer to do so when the size of the array can be explicitly determined.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule3-1-3"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 11.8: A cast shall not remove any const or volatile qualification from the typepointed to by a pointer: Although it is possible to declare an array of incomplete type and access its elements, it is safer to do so when the size of the array can be explicitly determined.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule3-1-3"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 11.9 The macro NULLshall be the only permitted form of integer null pointer constant: Although it is possible to declare an array of incomplete type and access its elements, it is safer to do so when the size of the array can be explicitly determined.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule3-1-3"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

Expressions

Statements

  • Rule 6–2–1: Assignement operators shall not be used in sub-expressions: Assignments used in a sub-expression add an additional side effect to that of the full expression, potentially resulting in a value inconsistent with developer expectations. In addition, this helps to avoid getting = and == confused.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule6-2-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–2–2: Floating-point expressions shall not be directly or indirectly tested for equality or inequality: The inherent nature of floating-point types is such that comparisons of equality will often not evaluate to true, even when they are expected to. Also, the behaviour of such a comparison cannot be predicted before execution, and may well vary from one implementation to another.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_floatingpoint_eq" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–2–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 character: Null statements should not normally be included deliberately, but where they are used, they shall appear on a line by themselves. White-space characters may precede the null statement to preserve indentation. If a comment follows the null statement, then at least one white-space character shall separate the null statement from the comment.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule6-2-3"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–3–1: The statement forming the body of a switch, while, do...while or for statement shall be a compound statement: If the bodies of these statements are not compound statements, then errors can occur if a developer fails to add the required braces when attempting to change a single statement body to a multi-statement body.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule6-3-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–4–1: 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: If the bodies of these constructs are not compound statements, then errors can occur if a developer fails to add the required braces when attempting to change a single statement body to a multi-statement body.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule6-4-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–4–2: All if ... elseif constructs shall be terminated with an else clause: When an if statement is followed by one or more else if statements then the final else if shall be followed by an else statement. In the case of a simple if statement the else statement need not be included. The final else statement, which should either take appropriate action or contain a suitable comment as to why no action is taken, is defensive programming.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule6-4-2"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6-4-3: A switch statement shall be a well-formed switch statement: A well-formed switch statement conforms to the following syntax rules, which are additional to the C++ standard syntax rules. All syntax rules not defined below areas defined in ISO/IEC14882:2003 [1].

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where  issue.Type=="warn_jump_out_of_scope" || issue.Type=="Rule6-6-2" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–4–4: A switch-label shall only be used when the most closely-enclosing compound statement is the body of a switch statement: A switch-label can be placed anywhere within the statements that form the body of a switch statement, potentially leading to unstructured code. To prevent this from happening, the scope of a case-label or default-label shall be the compound statement forming the body of a switchstatement. All case-clauses and the default-clause shall be at the same scope.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule6-4-4"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • A loop counter shall not have essentially Floating type: If a developer fails to add a break statement to the end of a switch-clause,then control flow “falls” into any following switch-clause. Whilst this is sometimes intentional, it is often an error.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_unannotated_fallthrough" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–4–6:The final clause of a switch statement shall be the default-clause: The requirement for a final default-clause is defensive programming. This clause shall either take appropriate action, or else contain a suitable comment as to why no action is taken.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule6-4-6"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–4–7: The condition of a switch statement shall not have bool type: An if statement gives a clearer representation for a Boolean choice.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_bool_switch_condition" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–4–8: Every switch statement shall have at least one case-clause: A switch statement with no case-clauses is redundant.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule6-4-8"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–6–1: Any label referenced by a goto statement shall be declared in the same block, or in a block enclosing the goto statement: Unconstrained use of goto can lead to programs that are extremely difficult to comprehend, analyse and, for C++, can also lead to the program exhibiting unspecified behaviour. However, in many cases a total ban on goto requires the introduction of flags to ensure correct control flow,and it is possible that these flags may themselves be less transparent than the goto they replace.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_jump_out_of_scope" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–6–2: The goto statement shall jump to a label declared later in the same function body: Unconstrained use of goto can lead to programs that are extremely difficult to comprehend,analyse and, for C++, can also lead to the program exhibiting unspecified behaviour. However, in many cases a total ban on goto requires the introduction of flags to ensure correct control flow, and it is possible that these flags may themselves be less transparent than the goto they replace.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where  issue.Type=="Rule6-6-2" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 6–6–5: A function shall have a single point of exit at the end of the function: This is required by IEC 61508 [12], as part of the requirements for a modular approach.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where  issue.Type=="Rule6-6-5" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

Declarations

Declarators

Classes

  • Rule 9–5–1: Unions shall not be used: The use of unions to access an object in different ways may result in the data being misinterpreted. Therefore, this rule prohibits the use of unions for any purpose.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule9-5-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 10–1–1: Classes should not be derived from virtual bases: The use of virtual base classes can introduce a number of undefined and potentially confusing behaviours. The use of virtual bases is not recommended.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule10-1-1"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 10–3–2: Each overriding virtual function shall be declared with the virtual keyword: Declaring overriding virtual functions with the virtual keyword removes the need to check the base class to determine whether a function is virtual.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule10-3-2"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 11–0–1: Member data in non-POD class types shall be private: By implementing class interfaces with member functions, the implementation retains more control over how the object state can be modified, and helps to allow a class to be maintained without affecting clients.

    This coding standard is computed with the following query:

    warnif count > 0 
    from f in JustMyCode.Fields where !f.ParentType.IsPOD && f.IsPublic
    select f

  • Rule 12–1–1: An object's dynamic type shall not be used from the body of its constructor or destructor: During construction and destruction of an object, its final type may be different to that of the completely constructed object. The result of using an object’s dynamic type in a constructor or destructor may not be consistent with developer expectations.

    This coding standard is computed with the following query:

    warnif count > 0 
    from m in JustMyCode.Methods where 
    (m.IsConstructor || m.IsDestructor)
    && (m.MethodsCalled.Where(vm=>vm.IsVirtual).Count()>0 || m.IsUsing("Keywords.dynamic_cast".AllowNoMatch()))
    select m

  • Rule 12–1–2: All constructors that are callable with a single argument of fundamental type shall be declared explicit: This rule reduces confusion over which constructor will be used, and with what parameters.

    This coding standard is computed with the following query:

    warnif count > 0 
    from m in JustMyCode.Methods where m.IsConstructor && m.Params.Count()==1 && m.Params.First().ParamType!=null
    && m.Params.First().ParamType.Name=="int" && !m.IsExplicitConstructor
    select m

  • Rule 12–8–2: The copy assignment operator shall be declared protected or private in an abstract class: An abstract class represents the interface part of a hierarchy. Invoking the copy constructor from the top of such a hierarchy bypasses the underlying implementation resulting in only the base sub-objects being copied.

    This coding standard is computed with the following query:

    warnif count > 0 
    from m in JustMyCode.Methods where m.SimpleName== "operator==" 
    && m.ParentType.IsAbstract && m.IsPublic 
    select m

Exceptions

  • Rule 15–0–2: An exception object should not have pointer type: If an exception object of pointer type is thrown and that pointer refers to a dynamically created object, then it may be unclear which function is responsible for destroying it, and when. This ambiguity does not exist if the object is caught by value or reference.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="Rule15-0-2"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 15–3–2: There should be at least one exception handler to catch all otherwise unhandled exceptions: If a program throws an unhandled exception it terminates in an implementation-defined manner. In particular, it is implementation-defined whether the call stack is unwound, before termination, so the destructors of any automatic objects may or may not be executed.

    This coding standard is computed with the following query:

    warnif count > 0 
    from m in JustMyCode.Methods where m.IsEntryPoint
    && m.IsUsing("Keywords.generic_catch".AllowNoMatch()) select m

  • Rule 15–3–5: A class type exception shall always be caught by reference: If a class type exception object is caught by value, slicing occurs. That is, if the exception object is of a derived class and is caught as the base, only the base class’s functions (including virtual functions) can be called. Also, any additional member data in the derived class cannot be accessed.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="catchExceptionByValue"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 15–3–7: Where multiple handlers are provided in a single try-catch statement or function-try-block, any ellipsis (catch-all) handler shall occur last: If the catch-all handler is found before any other handler, that behaviour will be performed. Any handlers after the catch-all are unreachable code and can never be executed.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_exception_caught_by_earlier_handler" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 15–5–1: A class destructor shall not exit with an exception: When an exception is thrown, the call stack is unwound up to the point where the exception is to be handled. The destructors for all automatic objects declared between the point where the exception is thrown and where it is to be handled will be invoked.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.Type=="exceptThrowInDestructor"
    select new { issue,issue.FilePath,Line=issue.BeginLine}

Preprocessor

  • Rule 16–0–3: #undef shall not be used: #undef should not normally be needed. Its use can lead to confusion with respect to the existence or meaning of a macro when it is used in the code.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_undef_used" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 16–0–7: Undefined macro identifiers shall not be used in #if or #elif preprocessor directives, except as operands to the defined operator: If an attempt is made to use an identifier in a preprocessor directive, and that identifier has not been defined, the preprocessor will assume the value zero.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_pp_undef_identifier" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 16–3–1: There shall be at most one occurrence of the # or ## operators in a single macro definition: The order of evaluation associated with both the # and ## preprocess or operators is unspecified. This problem can be avoided by having only one occurrence of either operator in any single macro definition(i.e.one#, or one ##or neither).

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_pp_hashhash_used" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule 16–3–2: The # and ## operators should not be used: The order of evaluation associated with both the # and ## preprocessor operators is unspecified. Compilers have been known to implement these operators inconsistently, therefore, to avoid these problems, do not use them.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang" && issue.Type=="warn_pp_hash_used" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

Library

Go to top


Scanyp offers a wide range of features. It is often described as a Swiss Army Knife for developers.

Start Free Trial
Useful Links
FeaturesScreenshotsStart Free TrialDocsEULA
Our products
CPPDEPEND for C/C++C/C++ SONARQUBE PLUGINJARCHITECT FOR JAVAVBDEPEND FOR VBA/VB6
Contact Us
www.codergears.comsupport@codergears.comsales@codergears.com

2009 - 2020 © All Rights Reserved. CoderGears / CppDepend