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 420
  • Vulnerability14
  • Bug111
  • Security Hotspot19
  • Code Smell276

  • Quick Fix 27
 
Tags
    Impact
      Clean code attribute
        1. Pointer and reference parameters should be "const" if the corresponding object is not modified

           Code Smell
        2. Non-standard characters should not occur in header file names in "#include" directives

           Bug
        3. Functions should not be declared at block scope

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

           Code Smell
        5. Digraphs should not be used

           Code Smell
        6. The first element of an array should not be accessed implicitly

           Code Smell
        7. A single L in a literal suffix should only be used for long values

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

           Code Smell
        9. Pointer and reference local variables should be "const" if the corresponding object is not modified

           Code Smell
        10. "sizeof" should not be called on pointers

           Bug
        11. Control characters should not be used in literals

           Code Smell
        12. Parameters should be passed in the correct order

           Code Smell
        13. Redundant casts should not be used

           Code Smell
        14. Multiple variables should not be declared on the same line

           Code Smell
        15. Unused local variables should be removed

           Code Smell
        16. Octal values should not be used

           Code Smell
        17. A "while" loop should be used instead of a "for" loop

           Code Smell
        18. Sections of code should not be commented out

           Code Smell
        19. Redundant pairs of parentheses should be removed

           Code Smell
        20. An "integer-literal" of type "long long" shall not use a single "L" or "l" in any suffix

           Code Smell
        21. The "'" or """ or "\" characters and the "/*" or "//" character sequences shall not occur in a "header file" name

           Bug
        22. A "declaration" should not declare more than one variable or member variable

           Code Smell
        23. The structure of a "switch" statement shall be appropriate

           Code Smell
        24. The lowercase form of "L" shall not be used as the first character in a literal suffix

           Code Smell
        25. Octal constants shall not be used

           Code Smell
        26. "Trigraph-like sequences" should not be used

           Code Smell
        27. A function shall not contain "unreachable" statements

           Bug

        The structure of a "switch" statement shall be appropriate

        intentionality - clear
        maintainability
        reliability
        Code Smell
        Quick FixIDE quick fixes available with SonarQube for IDE
        • misra-c++2023
        • misra-required

        Why is this an issue?

        More Info

        This rule is part of MISRA C++:2023.

        Usage of this content is governed by Sonar’s terms and conditions. Redistribution is prohibited.

        Rule 9.4.2 - The structure of a switch statement shall be appropriate

        [stmt.switch]
        [dcl.attr.fallthrough]

        Category: Required

        Analysis: Decidable,Single Translation Unit

        Amplification

        The substatement of a switch statement is called the switch body. It shall be a compound statement.

        A labeled statement, along with the complete chain of its substatements that are also labeled statements, is called a label group. A label group that is directly enclosed by a switch body is called a switch label group.

        The statements directly enclosed by a switch body are partitioned into switch branches, with each switch label group starting a new branch.

        A switch statement is structured appropriately when it conforms to the following restrictions:

        • The condition shall only be preceded by an optional simple-declaration;
        • case or default labeled statements shall only appear as part of a switch label group;
        • Switch label groups shall only contain case or default labeled statements;
        • The first statement in a switch body shall be a switch label group;
        • Every switch branch shall be unconditionally terminated by either:
          • A break statement; or
          • A continue statement; or
          • A return statement; or
          • A goto statement; or
          • A throw expression; or
          • A call to a [[noreturn]] function; or
          • A [[fallthrough]] attribute applied to a null statement.
        • Every switch statement shall have at least two switch branches;
        • Every switch statement shall have a default label, appearing as either the first label of the first switch label group or as the last label of the last switch label group.

        Rationale

        The syntax for the switch statement can be used to create complex, unstructured code. This rule places restrictions on the use of the switch statement in order to impose a simple and consistent structure:

        • A simple-declaration is permitted before the condition as it allows the declaration of a variable with restricted scope within a switch statement. An expression-statement is not permitted as the init-statement, as it introduces complexity without any extra benefit.
        • The C++ Standard permits a case label or default label to be placed before any statement contained within the body of a switch statement, potentially leading to unstructured code. To prevent this, a case label or default label is only permitted to appear at the outermost level of the compound statement forming the body of a switch statement.
        • Including labels other than case or default in a switch label group potentially allows unstructured control flow to be introduced.
        • A statement placed before a switch label group would either be an uninitialized variable or unreachable code.
        • If a developer fails to terminate a switch branch, then control flow "falls" into the following switch branch or, if there is no such branch, off the end and into the statement following the switch statement. The requirement for unconditional termination ensures that unintentional fall-throughs can be detected, with the [[fallthrough]] attribute being used to explicitly indicate when fall-through is intentional. Note: fall-through that occurs between two consecutive case or default labels having no intervening statements is not ambiguous, and is permitted by this rule.
        • A switch statement with a single switch branch is not permitted as it may be indicative of a programming error.
        • The requirement for a default label is defensive programming, complementing the requirement for if ... else if constructs to be terminated with an else (see M23_112: MISRA C++ 2023 Rule 9.4.1). The addition of a default, even when empty, indicates that consideration has been given regarding the behaviour when all other cases are not selected. Placing the default as the first or last label makes it easier to locate during code review.

        Note: even when the condition of a switch has enum type, listing all enumerators values in case labels does not make the use of default redundant as the value could still lie outside of the set of enumerators.

        Exception

        If the condition of a switch statement is an unscoped enumeration type that does not have a fixed underlying type, and all the enumerators are listed in case labels, then a default label is not required. Note: compliance with M23_061: MISRA C++ 2023 Rule 10.2.3 ensures that an object of such a type cannot be assigned values outside of its set of enumerators.

        Example

        The following switch statement has four switch branches:

        switch ( int8_t x = f(); x ) // Compliant - declaration of x is simple
        {
          case 1:
          {
            break;                   // Compliant - branch unconditionally terminated
          }
        
          case 2:
          case 3:
            throw;                   // Compliant - branch unconditionally terminated
        
          case 4:
            a++;
            [[fallthrough]];         // Compliant - branch has explicit fall-through
          default:                   // Compliant - default is last label
            b++;
            return;                  // Compliant - branches unconditionally terminated
        }
        

        The following switch statement has four switch branches:

        switch ( x = f(); x )        // Non-compliant - x = f() is not a simple-declaration
        {
          int32_t i;                 // Non-compliant - not a switch label group
        
          case 5:
            if ( ... )
            {
              break;
            }
            else
            {
              break;
            }
                                     // Non-compliant - termination is not unconditional
        
          case 6:
            a = b;                   // Non-compliant - non-empty, implicit fall-through
          case 7:
            {
              case 8:                // Non-compliant - case not in a switch label group
                DoIt();
            }
            break;
        }                            // Non-compliant - default is required
        
        switch ( x )                 // Non-compliant - only one switch branch
        {
          default:
            ;                        // Non-compliant - default must also be terminated
        }
        
        enum Colours { RED, GREEN, BLUE } colour;
        
        switch ( colour )
        {
          case RED:
            break;
          case GREEN:
            break;
        }                            // Non-compliant - default is required
        
        switch ( colour )
        {
          case RED:
          case GREEN:
            break;
          case BLUE:
            break;
        }                            // Compliant by exception - all enumerators listed
        
        switch ( colour )            // Non-compliant - only one switch branch
        {
          case RED:
          default:                   // Non-compliant - default must be first or last label
          case BLUE:
            break;
        }
        

        Copyright The MISRA Consortium Limited © 2023

          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

        © 2025 SonarSource Sàrl. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use