SonarSource Rules
  • Products

    In-IDE

    Code Quality and Security in your IDE with SonarQube Ide

    IDE extension that lets you fix coding issues before they exist!

    Discover SonarQube for IDE

    SaaS

    Code Quality and Security in the cloud with SonarQube Cloud

    Setup is effortless and analysis is automatic for most languages

    Discover SonarQube Cloud

    Self-Hosted

    Code Quality and Security Self-Hosted with SonarQube Server

    Fast, accurate analysis; enterprise scalability

    Discover SonarQube Server
  • SecretsSecrets
  • ABAPABAP
  • AnsibleAnsible
  • ApexApex
  • AzureResourceManagerAzureResourceManager
  • CC
  • C#C#
  • C++C++
  • CloudFormationCloudFormation
  • COBOLCOBOL
  • CSSCSS
  • DartDart
  • DockerDocker
  • FlexFlex
  • GitHub ActionsGitHub Actions
  • GoGo
  • HTMLHTML
  • JavaJava
  • JavaScriptJavaScript
  • JSONJSON
  • JCLJCL
  • KotlinKotlin
  • KubernetesKubernetes
  • Objective CObjective C
  • PHPPHP
  • PL/IPL/I
  • PL/SQLPL/SQL
  • PythonPython
  • RPGRPG
  • RubyRuby
  • RustRust
  • ScalaScala
  • ShellShell
  • SwiftSwift
  • TerraformTerraform
  • TextText
  • TypeScriptTypeScript
  • T-SQLT-SQL
  • VB.NETVB.NET
  • VB6VB6
  • XMLXML
  • YAMLYAML
C++

C++ static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your C++ code

  • All rules 674
  • Vulnerability13
  • Bug139
  • Security Hotspot19
  • Code Smell503

  • Quick Fix 91
 
Tags
    Impact
      Clean code attribute
        1. "abort", "exit", "getenv" and "system" from <stdlib.h> should not be used

           Bug
        2. "atof", "atoi" and "atol" from <stdlib.h> should not be used

           Bug
        3. "<signal.h>" should not be used

           Bug
        4. Dynamic heap memory allocation should not be used

           Bug
        5. Lines starting with "#" should contain valid preprocessing directives

           Bug
        6. Macros used in preprocessor directives should be defined before use

           Bug
        7. Function-like macros should not be invoked without all of their arguments

           Bug
        8. "#include" directives should be followed by either <filename> or "filename" sequences

           Bug
        9. Non-standard characters should not occur in header file names in "#include" directives

           Bug
        10. The address of an automatic object should not be assigned to another object that may persist after the first object has ceased to exist

           Bug
        11. Function exit paths should have appropriate return values

           Bug
        12. Evaluation of the operand to the sizeof operator shall not contain side effects

           Bug
        13. Non-empty statements should change control flow or have at least one side-effect

           Bug
        14. Unary minus should not be applied to an unsigned expression

           Bug
        15. Bitwise operators should not be applied to signed operands

           Bug
        16. Boolean operations should not have numeric operands, and vice versa

           Bug
        17. Objects with integer type should not be converted to objects with pointer type

           Bug
        18. Pointer conversions should be restricted to a safe subset

           Bug
        19. Function pointers should not be converted to any other type

           Bug
        20. Results of ~ and << operations on operands of underlying types unsigned char and unsigned short should immediately be cast to the operand's underlying type

           Bug
        21. Variables should be initialized before use

           Bug
        22. String literals with different prefixes should not be concatenated

           Bug
        23. Only escape sequences defined in the ISO C standard should be used

           Bug
        24. Macro arguments should not contain preprocessing directives

           Bug
        25. Variables should not be accessed outside of their scope

           Bug
        26. Coroutines should have well-defined exception behavior

           Bug
        27. The result of "make_format_args" should be passed directly as an argument

           Bug
        28. "std::format" numeric types should be 0-padded using the numerical padding and not the character padding

           Bug
        29. Arguments corresponding to width and precision formatting options should be integers

           Bug
        30. "std::format" should not be missing indexes

           Bug
        31. Type-constraints should not be used for forwarding reference parameters

           Bug
        32. Perfect forwarding constructors should be constrained

           Bug
        33. Requires-expression should not contain unevaluated concept checks or type predicates

           Bug
        34. Assigning to an optional should directly target the optional

           Bug
        35. Coroutine should have co_return on each execution path or provide return_void

           Bug
        36. Well-defined type-punning method should be used instead of a union-based one

           Bug
        37. Result of the standard remove algorithms should not be ignored

           Bug
        38. "std::cmp_*" functions should be used to compare unsigned values with negative values

           Bug
        39. "volatile" should not be used to qualify objects for which the meaning is not defined

           Bug
        40. "volatile" types should not be used in compound operations

           Bug
        41. "std::is_constant_evaluated" and "if consteval" should only be used when necessary

           Bug
        42. Heterogeneous sorted containers should only be used with types that support heterogeneous comparison

           Bug
        43. "std::scoped_lock" should be created with constructor arguments

           Bug
        44. Values returned from string find-related methods should not be treated as boolean

           Bug
        45. Objects should not be sliced

           Bug
        46. Relational and subtraction operators should not be used with pointers to different arrays

           Bug
        47. Arguments evaluation order should not be relied on

           Bug
        48. Immediately dangling references and pointers should not be created

           Bug
        49. "#pragma pack" should be used correctly

           Bug
        50. Enums should be consistent with the bit fields they initialize

           Bug
        51. "pthread_mutex_t" should be unlocked in the reverse order they were locked

           Bug
        52. "pthread_mutex_t" should be properly initialized and destroyed

           Bug
        53. "pthread_mutex_t" should not be locked when already locked, or unlocked when already unlocked

           Bug
        54. "std::move" and "std::forward" should not be confused

           Bug
        55. A call to "wait()" on a "std::condition_variable" should have a condition

           Bug
        56. Each operand of the ! operator, the logical && or the logical || operators shall have type bool

           Bug
        57. A pointer to a virtual base class shall only be cast to a pointer to a derived class by means of dynamic_cast

           Bug
        58. When an array is declared, its size shall either be stated explicitly or defined implicitly by initialization

           Bug
        59. "reinterpret_cast" should be used carefully

           Bug
        60. User-defined types should not be passed as variadic arguments

           Bug
        61. Class members should not be initialized with dangling references

           Bug
        62. Functions with "noreturn" attribute should not return

           Bug
        63. RAII objects should not be temporary

           Bug
        64. "memcmp" should only be called with pointers to trivially copyable types with no padding

           Bug
        65. "memcpy", "memmove", and "memset" should only be called with pointers to trivially copyable types

           Bug
        66. "std::auto_ptr" should not be used

           Bug
        67. Array values should not be replaced unconditionally

           Bug
        68. Integral operations should not overflow

           Bug
        69. "case" ranges should not be empty

           Bug
        70. All branches in a conditional structure should not have exactly the same implementation

           Bug
        71. Parameter values should be appropriate

           Bug
        72. "extern" shouldn't be used on member definitions

           Bug
        73. Declaration specifiers should not be redundant

           Bug
        74. Destructors should be "noexcept"

           Bug
        75. Stack allocated memory and non-owned memory should not be freed

           Bug
        76. Closed resources should not be accessed

           Bug
        77. Dynamically allocated memory should be released

           Bug
        78. Freed memory should not be used

           Bug
        79. Memory locations should not be released more than once

           Bug
        80. Memory access should be explicitly bounded to prevent buffer overflows

           Bug
        81. Zero should not be a possible denominator

           Bug
        82. Function declarations that look like variable declarations should not be used

           Bug
        83. "sizeof" should not be called on pointers

           Bug
        84. "const" references to numbers should not be made

           Bug
        85. Unary prefix operators should not be repeated

           Bug
        86. Non-existent operators like "=+" should not be used

           Bug
        87. Values of different "enum" types should not be compared

           Bug
        88. The "sizeof" and "alignof" operator should not be used with operands of a "void" type

           Bug
        89. "nonnull" parameters and return values of "returns_nonnull" functions should not be null

           Bug
        90. Conditionally executed code should be reachable

           Bug
        91. Line-splicing should not be used in "//" comments

           Bug
        92. Printf-style format strings should not lead to unexpected behavior at runtime

           Bug
        93. Null pointers should not be dereferenced

           Bug
        94. Single-bit named bit fields should not be of a signed type

           Bug
        95. "for" loop counters should not have essentially floating type

           Bug
        96. Recursion should not be infinite

           Bug
        97. Values should not be uselessly incremented

           Bug
        98. Member variables should be initialized

           Bug
        99. Resources should be closed

           Bug
        100. Line continuation characters '\' should not be followed by trailing whitespace

           Bug
        101. "sizeof(sizeof(...))" should not be used

           Bug
        102. Related "if/else if" statements should not have the same condition

           Bug
        103. Pointers should not be cast to integral types

           Bug
        104. Identical expressions should not be used on both sides of a binary operator

           Bug
        105. All code should be reachable

           Bug
        106. Loops with at most one iteration should be refactored

           Bug
        107. The original exception object should be rethrown

           Bug
        108. Variables should not be self-assigned

           Bug
        109. "operator delete" should be written along with "operator new"

           Bug
        110. Floating point numbers should not be tested for equality

           Bug
        111. Appropriate memory de-allocation should be used

           Bug
        112. Destructors should not throw exceptions

           Bug
        113. Condition-specific "catch" handlers should not be used after the ellipsis (catch-all) handler

           Bug
        114. Handlers in a single try-catch or function-try-block for a derived class and some or all of its bases should be ordered most-derived-first

           Bug
        115. Exception classes should be caught by reference

           Bug
        116. 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

           Bug
        117. Empty throws ("throw;") should only be used in the compound statements of catch handlers

           Bug
        118. An exception object should not have pointer type

           Bug
        119. Accessible base classes should not be both "virtual" and non-virtual in the same hierarchy

           Bug
        120. Multiple declarations for an identifier in the same namespace shall not straddle a using-declaration for that identifier

           Bug
        121. An object shall not be accessed outside of its lifetime

           Bug
        122. A function declared with the "[[noreturn]]" attribute shall not return

           Bug
        123. An "explicit type conversion" shall not be an "expression statement"

           Bug
        124. Reads and writes on the same file stream shall be separated by a positioning operation

           Bug
        125. Line-splicing shall not be used in "//" comments

           Bug
        126. A pointer to an incomplete "class" type shall not be deleted

           Bug
        127. The result of "std::remove", "std::remove_if", "std::unique" and "empty" shall be "used"

           Bug
        128. A comparison of a "potentially virtual" pointer to member function shall only be with "nullptr"

           Bug
        129. The "#include" directive shall be followed by either a "<filename>" or ""filename"" sequence

           Bug
        130. A "noexcept" function should not attempt to propagate an exception to the calling function

           Bug
        131. An exception of "class" type shall be caught by "const" reference or reference

           Bug
        132. Handlers for a "function-try-block" of a constructor or destructor shall not refer to non-static members from their class or its bases

           Bug
        133. An exception object shall not have pointer type

           Bug
        134. A named bit-field with "signed integer type" shall not have a length of one bit

           Bug
        135. The value of an object must not be read before it has been set

           Bug
        136. A virtual base class shall only be cast to a derived class by means of "dynamic_cast"

           Bug
        137. A line whose first token is "#" shall be a valid preprocessing directive

           Bug
        138. All identifiers used in the controlling expression of "#if" or "#elif" preprocessing directives shall be defined prior to evaluation

           Bug
        139. Tokens that look like a preprocessing directive shall not occur within a macro argument

           Bug

        Well-defined type-punning method should be used instead of a union-based one

        intentionality - logical
        reliability
        Bug
        • symbolic-execution
        • bad-practice
        • pitfall

        union is unsuitable for type-punning in C++ code, leading to undefined behavior. There are well-defined safe alternatives that are just as fast.

        Why is this an issue?

        How can I fix it?

        More Info

        In some performance-oriented algorithms, a solution to certain slow operations is reinterpreting a value as a different type of the same length while preserving its binary representation.

        One of the superseded solutions, known as "union type-punning", is to use a union with two members with types corresponding to the source and the target types of the cast. The operation is performed by saving the value in the member of the source type and then reading the value from the member of the target type. Despite being allowed in C, this operation has undefined behavior according to C++ standard and should be replaced by std::memcpy (or std::bit_cast in C++20).

        Note: std::memcpy has no performance impact on modern compilers when used in type-punning and is optimized during compilation.

        Sometimes union type-punning is used to remove const. This can create readability issues and should be replaced with const_cast.

        This rule raises an issue on any use of a union that should be replaced with std::memcpy, std::bit_cast, or const_cast.

        What is the potential impact?

        The C++ standard states that only one union member can be "active" at any time. A member becomes active once assigned a value, making the other union members "inactive". The standard also states that reading from an "inactive" member is undefined behavior.

        Since union type-punning relies on reading the "inactive" member, code using it exercises undefined behavior. Such code can be unintentionally removed in aggressive levels of optimization.

        Further problems could also arise from using union-based type punning in cross-platform solutions. Since this method is mainly used with Built-in Types, which vary in size depending on the underlying architecture, it could hide a portability issue.

          Available In:
        • SonarQube IdeCatch issues on the fly,
          in your IDE
        • SonarQube CloudDetect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories
        • SonarQube ServerAnalyze code in your
          on-premise CI
          Developer Edition
          Available Since
          9.1

        © 2008-2025 SonarSource SA. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use