CoderGears Logo
Download Free Trial
Start Free Trial
Boost Your Autosar C++ Compliance with CppDepend

Achieve Autosar C++ Guidelines Compliance with CppDepend

Introduction

Are you struggling to maintain Autosar C++ 2014 compliance in your automotive software projects? Look no further. CppDepend is here to streamline your code analysis process and ensure adherence to the stringent Autosar C++ guidelines. In this article, we'll explore how CppDepend automates compliance checks, improves code quality, and reduces time to market for your automotive software. Say goodbye to manual code reviews and embrace the power of CppDepend to achieve seamless Autosar C++ compliance.

To learn Autosar C++ 2014 Standards, you can print the Guidelines for the use of the C++14 language in critical and safety-related systems pdf by AUTOSAR.

Using Autosar C++ 2014 Rules in CppDepend

When you create a new CppDepend Project, a pop-up will appear displaying all the coding standards you would like to include in your analysis. To include Autosar coding standards, check the Autosar C++ 2014 option.

Autosar rules in CppDepend

After analyzing your project, Navigate to the Queries and Rules Explorer section, and select the Autosar C++ 2014 Rules from the left-hand menu (Highlighted in red in the image below). This will display all the related Autosar C++ 2014 rules on the right. Upon clicking a Rule, the corresponding CQLinq query and the relevant source code will be automatically generated. Additionally, the Metrics View section provides a visualization of the issue's location and significance.

Autosar rules in CppDepend

Incorporating Misra Rules into the HTML Report

To include the Misra rules in the generated HTML Report (available in the DevOps Edition), simply right-click on the Autosar C++ 2014 group and select "List Code Queries of this Group in a dedicated section in Report."

Add Autosar Rules to Report

List of Autosar C++ 2014 Rules

CppDepend offers support for 103 Autosar C++ 2014 standard queries.

To gain a deeper understanding of each rule and its functionality, please consult these Guidelines for the use of the C++14 language in critical and safety-related systems pdf.

Uncessary Constructs

  • Rule M0–1–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 M0–1–2: A project shall not contain infeasible paths:

    This coding standard is computed with the following query:

    Infeasible paths occur where there is a syntactic path but the semantics ensure that the control flow path cannot be executed by any input data. One of the major problems here is the explosion of infeasible paths caused by: - if ... else statement sequences - Sequences of poorly chosen loop constructs Errors in conditions and poorly designed logic contribute to this problem. It is always possible to rewrite the code to eliminate these constructs. This process may then reveal faults.

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

  • Rule M0–1–3: A project shall not contains unused variables: Variables declared and never used in a project constitute noise and may indicate that the wrong variable name has been used somewhere. Removing these declarations reduces the possibility that they may later be used instead of the correct variable.

    This coding standard is computed with the following query:

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

  • Rule M0–1–4: A project shall not contain non-volatile POD variable having only one use: With the exception of volatile variables, variables declared and used only once do not contribute to program computations. A use is either an assignment (explicit initialization) or a reference. These variables are essentially noise but their presence may indicate that the wrong variable has been used elsewhere. Missing statements contribute to this problem.

    This coding standard is computed with the following query:

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

  • Rule M0–1–5: 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 A0-1-1: A project shall not contain instances of non-volatile variables being given values that are not subsequently used:

    This coding standard is computed with the following query:

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

  • Rule A0-1-2: The value returned by a function having a non-voidreturn type that is not an overloaded operator shall always be used:

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Misra" && issue.Type=="Rule0-1-7" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule M0-1-9: There shall be no dead code: Any executed statement whose removal would not affect program output constitutes dead code(also know as redundant code). It is unclear to a reviewer if this is intentional or has occurred due to 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_unreachable" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule M0–1–11: There shall be no unused parameters in non virtual 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" 
    && issue.RelatedMethod!=null && issue.RelatedMethod.IsVirtual
    select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule M0-1-12: 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: 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" 
    && issue.RelatedMethod!=null && !issue.RelatedMethod.IsVirtual
    select  new { issue,issue.FilePath,Line=issue.BeginLine}

Storage

  • Rule M0–2–1: An object shall not be assigned to an overlapping object: Assigning between objects that have an overlap in their physical storage leads to undefined behaviour.

    This coding standard is computed with the following query:

    warnif count > 0         
    from issue in ImportedIssues where issue.ToolName=="Clang-Tidy" && issue.Type=="cppcoreguidelines-pro-type-union-access" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

Arithmetic

  • Rule A0-4-2: Type long double shall not be used:

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Misra" && issue.Type=="Rule0-1-7" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

Lexical Conventions

  • Rule A2–5–1: 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 A2-6-1: Digraphs shall not be used: The use of digraphs may not meet developer expectations.

    This coding standard is computed with the following query:

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

  • RuleA2-11-1: 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 M2-10-6: If an identifier refers to a type, it shall not also refer to an object or a function in the same scope: For C compatibility, it is possible in C++ for a name to refer to both a type and object or a type and function. This can lead to confusion.

    This coding standard is computed with the following query:

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

  • Rule A2-14-1: Only those escape sequences that are defined in ISO/IEC 14882:2003 shall be used: The use of an undefined escape sequence leads to undefined behaviour.
    The defined escape sequences(ISO/IEC14882:2003[1]§2.13.2)are:\n, \t, \v, \b, \r, \f, \a, \\, \?, \', \", \<Octal Number>, \x<Hexadecimal Number>

    This coding standard is computed with the following query:

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

  • Rule M2-13-3: 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 M2-13-4: 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}

  • Rule A2-8-1:The character \ shall not occur as a last character of a C++ comment: 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}

  • Rule A2-14-2:String literals with different encoding prefixes shall not be concatenated: 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}

  • Rule A2-14-3:Type wchar_t shall not be used: 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}

  • Rule A2-11-2:A “using” name shall be a unique identifier within a namespace: // 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}

Basic Concepts

  • Rule A3–1–1: It shall be possible to include any header file in multiple translationunits without violating the one definition rule: 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 M3–1–2: Functions shall not be declared at block scope: 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 A3–1–4: 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 A3–3–1: Functions with extern linkage shall be declared in a header file: Placing the declarations of objects and functions with external linkage in a header file documents that they are intended to be accessible from other translation units. If external linkage is not required, then the object or function shall either be declared in an unnamed namespace or declared static. This will reduce the visibility of objects and functions, which is considered to be good practice.

    This coding standard is computed with the following query:

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

  • Rule M3–3–2: If a function has internal linkage then all re-declarations shall include the static storage class specifier: If the declaration of a function includes the static storage class specifier, then it has internal linkage.A re-declaration of such a function is not required to have the static keyword, but it will still have internal linkage. However, this is implicit and may not be obvious to a developer. It is therefore good practice to apply the static keyword consistently so that the linkage is explicitly stated.

    This coding standard is computed with the following query:

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

  • Rule M3–4–1: An identifier declared to be an object or type shall be defined in a block that minimizes its visibility: Defining variables in the minimum block scope possible reduces the visibility of those variables and therefore reduces the possibility that these identifiers will be used accidentally. Acorollaryof this is that global objects (including singleton function objects) shall be used in more than one function.

    This coding standard is computed with the following query:

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

  • Rule A3–9–2: typedefs that indicate size and signedness should be used in place of the basic numerical types: The basic numerical types of char, int, short, long, float, double and long double should not be used,but specific-length typedefs should be used. This rule helps to clarify the size of the storage, but does not guarantee portability because of the asymmetric behaviour of integral promotion.

    This coding standard is computed with the following query:

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

Standard Conversions

Expressions

  • Rule A5–0–1:The value of an expression shall be the same under any order of evaluation that the standard permits: Apart from a few operators (notably &&, ||, ?: and , (comma)) the order in which sub-expressions are evaluated is unspecified and can vary. This means that no reliance can be placed on the order of evaluation of sub-expressions and, in particular, no reliance can be placed on the order in which side effects occur. Those points in the evaluation of an expression at which all previous side effects can be guaranteed to have taken place are called “sequence points”. Sequence points and side effects are described in Section 1.9(7) of ISO/IEC 14882:2003 [1].

    This coding standard is computed with the following query:

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

  • Rule M5–0–4 : An implicit integral conversion shall not change the signedness of the underlying type: Some signed to unsigned conversions may lead to implementation-defined behaviour. This behaviour may not be consistent with developer expectations.

    This coding standard is computed with the following query:

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

  • Rule M5–0–5: There shall be no implicit floating-integral conversions: Conversions from floating point to integral types discard information,and may lead to undefined behaviour if the floating-point value cannot be represented in the integral type. Conversions from integral types to floating point types may not result in an exact representation,which may not be consistent with developer expectations.

    This coding standard is computed with the following query:

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

  • Rule M5–0–6: An implicit integral or floating-point conversion shall not reduce the size of the underlying type: An implicit conversion that results in the size of a type being reduced may result in a loss of information.

    This coding standard is computed with the following query:

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

  • Rule M5-0-7: There shall be no explicit floating-integral conversions of a cvalue expression: A cast applied to the result of an expression does not change the type in which the expression is evaluated, which may be contrary to developer expectations.

    This coding standard is computed with the following query:

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

  • Rule M5–0–9: An explicit integral conversion shall not change the signedness of the underlying type of a cvalue expression: A signed to unsigned conversion may lead to an expression having a value inconsistent with developer expectations.

    This coding standard is computed with the following query:

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

  • Rule M5–0–15: Array indexing shall be the only form of pointer arithmetic: Array indexing is the only acceptable form of pointer arithmetic, because it is clearer and hence less error prone than pointer manipulation. This rule bans the explicit calculation of pointer values. Array indexing shall only be applied to objects defined as an array type. Any explicitly calculated pointer value has the potential to access unintended or invalid memory addresses. Pointers may go out of bounds of arrays or structures, or may even point to effectively arbitrary locations.

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang-Tidy" && issue.Type=="cppcoreguidelines-pro-bounds-pointer-arithmetic" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule M5–0–18: >, >=, <, <= shall not be applied to objects of pointer type, except where they point to the same array: Attempting to make comparisons between pointers will produce undefined behaviour if the two pointers do not point to the same object. Note: it is permissible to address the next element beyond the end of an array, but accessing this element is not allowed.

    This coding standard is computed with the following query:

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

  • Rule A5-1-2: Variables shall not be implicitly captured in a lambda expression:

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang-Tidy" && issue.Type=="cppcoreguidelines-pro-bounds-pointer-arithmetic" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule M5–2–2: A pointer to a virtual base class shall only be cast to a pointer to a derived class by means of dynamic_cast: Casting from a virtual base to a derived class, using any means other than dynamic_cast has undefined behaviour. The behaviour for dynamic_cast is defined.

    This coding standard is computed with the following query:

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

  • Rule A5–2–2: C-style casts(other than void casts) and functional notation casts (other than explicit constructor calls) shall not be used: C-style (cast notation), and functional notation casts that do not invoke a converting constructor are capable of performing casts between unrelated types.

    This coding standard is computed with the following query:

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

  • Rule M5–2–6: A cast shall not convert a pointer to a function to any other pointer type, including a pointer to function type:

    This coding standard is computed with the following query:

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

  • Rule M5–3–3: The unary & operator shall not be overloaded: Taking the address of an object of incomplete type where the complete type contains a user declared operator & leads to undefined behaviour.

    This coding standard is computed with the following query:

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

  • Rule M5–3–4: Evaluation of the operand to the sizeof operator shall not contain side effects: A possible programming error in C++ is to apply the sizeof operator to an expression and expect the expression to be evaluated. However, the expression is not evaluated as sizeof only acts on the type of the expression. To avoid this error, sizeof shall not be used on expressions that would contain side effects if they were used elsewhere, as the side effects will not occur.

    This coding standard is computed with the following query:

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

  • Rule M5–8–1: 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: It is undefined behaviour if the right hand operand is negative, or greater than or equal to the width of the left hand operand. If, for example, the left hand operand of a left-shift or right-shift is a 16-bit integer, then it is important to ensure that this is shifted only by a number between 0 and 15 inclusive.

    This coding standard is computed with the following query:

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

  • Rule M5–14–1: The right hand operand of a logical && or || operator shall not contain side effects: There are some situations in C++ where certain parts of expressions may not be evaluated. If these sub-expressions contain side effects then those side effects may or may not occur, depending on the values of other sub expressions.

    This coding standard is computed with the following query:

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

  • Rule M5–18–1: The comma operator shall not be used: Use of the comma operator is generally detrimental to the readability of code, and the same effect can be achieved by other means.

    This coding standard is computed with the following query:

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

  • Rule A5-2-1: dynamic_cast should not be used:

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang-Tidy" && issue.Type=="cppcoreguidelines-pro-bounds-pointer-arithmetic" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule A5-2-3: A cast shall not remove any const or volatile qualification from the type of a pointer or reference:

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang-Tidy" && issue.Type=="cppcoreguidelines-pro-bounds-pointer-arithmetic" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule A5-2-4: reinterpret_cast shall not be used:

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang-Tidy" && issue.Type=="cppcoreguidelines-pro-bounds-pointer-arithmetic" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule A5-2-5: An array shall not be accessed beyond its range:

    This coding standard is computed with the following query:

    warnif count > 0 
    from issue in ImportedIssues where issue.ToolName=="Clang-Tidy" && issue.Type=="cppcoreguidelines-pro-bounds-pointer-arithmetic" select 
    new { issue,issue.FilePath,Line=issue.BeginLine}

  • Rule M5-2-11: The comma operator, && operator and the || operator shall not be overloaded: Taking the address of an object of incomplete type where the complete type contains a user declared operator & leads to undefined behaviour.

    This coding standard is computed with the following query:

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

  • >Rule A5-3-1:Evaluation of the operand to the typeid operator shall not contain side effects: Apart from a few operators (notably &&, ||, ?: and , (comma)) the order in which sub-expressions are evaluated is unspecified and can vary. This means that no reliance can be placed on the order of evaluation of sub-expressions and, in particular, no reliance can be placed on the order in which side effects occur. Those points in the evaluation of an expression at which all previous side effects can be guaranteed to have taken place are called “sequence points”. Sequence points and side effects are described in Section 1.9(7) of ISO/IEC 14882:2003 [1].

    This coding standard is computed with the following query:

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

Statements

Declarations

Declarators

Classes

  • Rule M9–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 A10–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

  • Rule 17–0–1: Reserved identifiers, macros and functions in the standard library shall not be defined, redefined or undefined: It is generally bad practice to #undef a macro that is defined in the standard library. It is also bad practice to #define a macro name that is a C++ reserved identifier, or C++ keyword or the name of any macro,object or function in the standard library. For example,there are some specific reserved words and function names that are known to give rise to undefined behaviour if they are redefined or undefined, including defined, __LINE__, __FILE__, __DATE__, __TIME__, __STDC__, errno and assert.

    This coding standard is computed with the following query:

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

  • Rule 17–0–5: The setjmp macro and the longjmp function shall not be used: setjmp and longjmp allow the normal function call mechanisms to be bypassed, and shall not be used,since exception handling provides a better defined mechanism for this.

    This coding standard is computed with the following query:

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

  • Rule 18–0–1: The C library shall not be used: Some C++ libraries (e.g. ) also have corresponding C versions (e.g. ). This rule requires that the C++ version is used.

    This coding standard is computed with the following query:

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

  • Rule 18–0–2: The library functions atof, atoi and atol from library cstdlib shall not be used: These functions have undefined behaviour associated with them when the string cannot be converted.

    This coding standard is computed with the following query:

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

  • Rule 18–0–3: The library functions abort, exit, getenv and system from library cstdlib shall not be used: The use of these functions leads to implementation-defined behaviour.

    This coding standard is computed with the following query:

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

  • Rule 18–0–4:The time handling functions of library shall not be used: Various aspects are implementation-defined or unspecified, such as the formats of times.

    This coding standard is computed with the following query:

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

  • Rule 18–0–5: The unbounded functions of library cstring shall not be used: The strcpy, strcmp, strcat, strchr, strspn, strcspn, strpbrk, strrchr, strstr, strtok and strlen functions within the library can read or write beyond the end of a buffer, resulting in undefined behaviour.Ideally, a safe string handling library should be used.

    This coding standard is computed with the following query:

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

  • Rule 18–2–1: The macro offsetof shall not be used: Use of this macro can lead to undefined behaviour when the types of the operands are incompatible, or when bit fields are used.

    This coding standard is computed with the following query:

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

  • Rule 18–4–1: Dynamic heap memory allocation shall not be used: The use of dynamic memory can lead to out-of-storage run-time failures, which are undesirable. The built-in new and delete operators, other than the placement versions, use dynamic heap memory. The functions calloc, malloc, realloc and free also use dynamic heap memory.There is a range of unspecified, undefined and implementation-defined behaviour associated with dynamic memory allocation, as well as a number of other potential pitfalls. Dynamic heap memory allocation may lead to memory leaks, data inconsistency, memory exhaustion, non-deterministic behaviour.

    This coding standard is computed with the following query:

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

  • Rule 18–7–1: The signal handling facilities of csignal shall not be used: Signal handling contains implementation-defined and undefined behaviour.

    This coding standard is computed with the following query:

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

  • Rule 19–3–1: The error indicator errno shall not be used: errno is a facility of C++ which should in theory be useful, but which in practice is poorly defined by ISO/IEC 14882:2003 [1]. A non-zero value may or may not indicate that a problem has occurred; therefore errno shall not be used.Even for those functions for which the behaviour of errno is well defined, it is preferable to check the values of inputs before calling the function rather than relying on using errno to trap errors.

    This coding standard is computed with the following query:

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

  • Rule 27–0–1: The stream input/output library shall not be used: This includes file and I/O functions fgetpos, fopen, ftell, gets, perror, remove, rename, etc. Streams and file I/O have a large number of unspecified, undefined and implementation-defined behaviours associated with them.

    This coding standard is computed with the following query:

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

Go to top


CppDepend offers a wide range of features. It is often described as a Swiss Army Knife for C and C++ 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 - 2024 © All Rights Reserved. CoderGears / CppDepend