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
  • 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 315
  • Vulnerability13
  • Bug76
  • Security Hotspot19
  • Code Smell207

  • Quick Fix 19
Filtered: 34 rules found
pitfall
    Impact
      Clean code attribute
        1. "goto" should jump to labels declared later in the same function

           Code Smell
        2. Dynamic heap memory allocation should not be used

           Bug
        3. "setjmp" and "longjmp" should not be used

           Code Smell
        4. Macros should not be #define'd or #undef'd within a block

           Code Smell
        5. Object declarations should contain no more than 2 levels of pointer indirection

           Code Smell
        6. Functions without parameters should be declared with parameter type "void"

           Code Smell
        7. Recursion should not be used

           Code Smell
        8. Functions should not be defined with a variable number of arguments

           Code Smell
        9. Constants of unsigned type should have a "U" suffix

           Code Smell
        10. If a function has internal linkage then all re-declarations shall include the static storage class specifer

           Code Smell
        11. Literal suffix "L" for long integers shall be upper case

           Code Smell
        12. Macro arguments should not contain preprocessing directives

           Bug
        13. All the elements of an aggregate should be provided with an initial value

           Code Smell
        14. Macros should not be used as replacements for "typedef" and "using"

           Code Smell
        15. Keywords shall not be used as macros identifiers

           Code Smell
        16. Logical operators should not be confused with bitwise operators

           Code Smell
        17. Include directives should not rely on non-portable search strategy

           Code Smell
        18. "#include" paths should be portable

           Code Smell
        19. Array indices should be placed between brackets

           Code Smell
        20. Bit fields should not be used

           Code Smell
        21. Conditionally executed code should be reachable

           Bug
        22. Control characters should not be used in literals

           Code Smell
        23. Octal and hexadecimal escape sequences should be terminated

           Code Smell
        24. Preprocessor directives should not be indented

           Code Smell
        25. "goto" statements should not be used to jump into blocks

           Code Smell
        26. Related "if/else if" statements should not have the same condition

           Bug
        27. "static" should not be used for the size of an array parameter

           Code Smell
        28. "switch" statements should not be nested

           Code Smell
        29. The sign of an unsigned variable should not be tested

           Code Smell
        30. Octal values should not be used

           Code Smell
        31. "for" loop stop conditions should be invariant

           Code Smell
        32. Control structures should use curly braces

           Code Smell
        33. Variables should not be shadowed

           Code Smell
        34. Control should not be transferred into a complex logic block using a "goto" or a "switch" statement

           Code Smell

        Variables should not be shadowed

        intentionality - clear
        maintainability
        Code Smell
        • based-on-misra
        • cert
        • suspicious
        • pitfall

        Why is this an issue?

        More Info

        Variable shadowing happens when a variable declared in a specific scope has the same name as a variable in an outer scope.

        This can lead to three main problems:

        • Confusion: The same name can refer to different variables in different parts of the scope, making the code hard to read and understand.
        • Unintended Behavior: You might accidentally use the wrong variable, leading to hard-to-detect bugs.
        • Maintenance Issues: If the inner variable is removed or renamed, the code’s behavior might change unexpectedly because the outer variable is now being used.

        To avoid these problems, rename the shadowing, shadowed, or both variables to accurately represent their purpose with unique and meaningful names.

        The examples below show typical situations in which shadowing can occur.

        • Parameter shadowing
          void f(int x, bool b) {
            int y = 4;
            if (b) {
              int x = 7; // Noncompliant: the parameter "x" is shadowed.
              int y = 9; // Noncompliant: the local variable "y" is shadowed.
              // ...
            }
          }
          
        • Member variable shadowing
          class Foo {
          private:
            int myField;
          
          public:
            void doSomething() {
              int myField = 0; // Noncompliant: Foo::myField is shadowed.
              // ...
            }
          };
          
        • Global variable shadowing
          namespace ns {
            int state;
          
            void bar() {
              int state = 0; // Noncompliant: the namespace variable is shadowed.
            }
          }
          

        Exceptions

        It is common practice to have constructor arguments shadowing the fields they initialize in the member initializer list. This pattern avoids the need to select new names for the constructor arguments and will not be reported by this rule.

        class Point {
        public:
          Point(int x, int y)
            : x(x) // Compliant by exception: the parameter "x" is used
                   // in the member initializer list.
          {
            y = y; // Noncompliant: the parameter is assigned to itself
                   // and the member "y" is not initialized.
          }
        
        private:
          int x;
          int y;
        };
        

        Caveats

        Shadowing in if, else if, and else

        Variables can be introduced in the condition of an if statement. Their scope includes the optional else statement, which may be surprising. Consequently, such variables can be shadowed in an else if statement. This can be even more confusing and result in unintended behavior, as illustrated in this example:

        using ExpectedData = std::expected<std::string, std::error_code>;
        
        if (ExpectedData e = readData()) {
          printMessage(e.value());
        } else if (ExpectedData e = readFallbackSource()) { // Noncompliant
          printMessage(e.value());
        } else {
          logError(
            "Initial source failed with: ",
            e.error() // Contrary to the intention, the second "e" is used.
          );
        }
        

        Shadowing of inaccessible declarations

        This rule also raises issues on some variables, although they do not shadow another variable according to a strict interpretation of the C++ language. There are mainly two reasons for this.

        1. Primarily, the readability and maintainability of the code are impaired. Readers need an advanced understanding of the C++ language to understand the subtle differences.
        2. Secondly, a small change can lead to actual shadowing. This can lead to subtle bugs when updating the code.

        Here is an example with nested classes:

        class A {
        public:
          int x;
          class B;
        };
        
        class A::B {
          void f(int x) { // Noncompliant: The parameter "x" shadows the field "A::x".
            // ...
          }
        };
        

        In the above example, A::x cannot be used from A::B member functions because it is not a static field. This can lead to surprising effects when moving code around, particularly if the declaration of A::x was changed from int x; to static int x;.

        You should always avoid shadowing to avoid any confusion and increase the maintainability of your code.

          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