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: 10 rules found
cppcoreguidelines
    Impact
      Clean code attribute
        1. Function-like macros should not be used

           Code Smell
        2. Boolean operations should not have numeric operands, and vice versa

           Bug
        3. A cast shall not remove any const or volatile qualification from the type of a pointer or reference

           Code Smell
        4. Loop variables should be declared in the minimal possible scope

           Code Smell
        5. Relational and subtraction operators should not be used with pointers to different arrays

           Bug
        6. Arguments evaluation order should not be relied on

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

           Bug
        8. Local variables and member data should not be volatile

           Code Smell
        9. Types and variables should be declared in separate statements

           Code Smell
        10. Type specifiers should be listed in a standard order

           Code Smell

        Boolean operations should not have numeric operands, and vice versa

        intentionality - complete
        reliability
        Bug
        • cppcoreguidelines
        • based-on-misra
        • cert

        Why is this an issue?

        More Info

        There are several constructs in the language that work with boolean:

        • If statements: if (b) ...
        • Conditional operator: int i = b ? 0 : 42;
        • Logical operators: (b1 || b2) && !b3

        Those operations would also work with arithmetic or enum values operands, because there is a conversion from those types to bool. However, this conversion might not always be obvious, for instance, an integer return code might use the value 0 to indicate that everything worked as expected, but converted to boolean, this value would be false, which often denotes failure. Conversion from integer to bool should be explicit.

        Moreover, a logical operation with integer types might also be a confusion with the bitwise operators (&, | and ~).

        Converting a pointer to bool to check if it is null is idiomatic and is allowed by this rule. We also allow the use of any user-defined type convertible to bool (for instance std::ostream), since they were specifically designed to be used in such situations. What this rule really detects is the use or arithmetic types (int, long…​) and of enum types.

        On the other hand, arithmetic operations are defined with booleans, but usually make little sense (think of adding two booleans). Booleans should not be used in an arithmetic context.

        Finally, comparing a boolean with the literals true or false is unnecessarily verbose, and should be avoided.

        Noncompliant code example

        if ( 1 && ( c < d ) ) // Noncompliant
        if ( ( a < b ) && ( c + d ) ) // Noncompliant
        if ( u8_a && ( c + d ) ) // Noncompliant
        if ( !0 ) // Noncompliant, always true
        if ( !ptr ) // Compliant
        if ( ( a < b ) && ( c < d ) ) // Compliant
        if ( !false ) // Compliant
        if (!!a) // Compliant by exception
        if ( ( a < b ) == true) // Noncompliant
        

        Compliant solution

        if ( 1 != 0 && ( c < d ) ) // Compliant, but left operand is always true
        if ( ( a < b ) && ( c + d ) != 0 ) // Compliant
        if ( u8_a != 0 && ( c + d ) != 0) // Compliant
        if ( 0 == 0 ) // Compliant, always true
        if ( a < b )
        

        Exceptions

        Some people use !! as a shortcut to cast an integer to bool. This usage of the ! operator with an integer argument is allowed for this rule.

          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