MISRA Discussion Forums - 6.6 Statements (C++)

Rule 6-2-2 Usage of std::fpclassify

Mon, 21 Sep 2026 08:37:41 +0000

Hi,

We have seen a creative way to work around MISRA Rule 6-2-2:

Code:
float x = ...;

float y = ...;

if (x == 0.F)  // non-compliant

if (x == y)    // non-compliant

if (std::fpclassify(x)     == FP_ZERO)  // compliant?

if (std::fpclassify(x - y) == FP_ZERO)  // compliant?

Would the last 2 examples be compliant with the rule?

We argue that this is an indirect test for equality and thus non-compliant.

MISRA C++ 2008 Rule 6-1-1 Clarification

Tue, 27 May 2025 20:10:11 +0000

Given the headline text of MISRA C++ 2008 Rule 6-1-1, MISRA C++ 2023 Rule 9.6.2 seems to be the equivalent rule in this case. MISRA C++ 2023 Rule 9.6.2 includes the following non-compliant example:

Code:
switch(i)

{

    case 0:

      if(x < y)

        goto L3;            // Non-compliant

      break;

    case 1:

    L3:

      break;

}

This example seems to echo an amplification made in the MISRA C 2012 Rule 15.3 (that has the same headline text as MISRA C++ 2008 Rule 6-1-1), which states:

Quote:For the purposes of this rule, a switch-clause that does not consist of a compound statement is treated as if it were a block.

It would be greatly appreciated if you could clarify whether the above example was also intended to violate MISRA C++ Rule 6-1-1.

C++17 [[fallthrough]]; attribute and (Rule 6-4-3 and Rule 6-4-5)

Mon, 22 Apr 2024 18:29:43 +0000

Given the response from: Rule 6-2-3 and C++17 [[fallthrough]]; attribute (misra.org.uk)
Should Rule 6-4-3(A switch statement shall be a well-formed switch statement) and Rule 6-4-5(An unconditional throw or break statement shall terminate every non-empty switch-clause) also have an exception for the [[fallthrough]]; attribute when used in an empty switch case?

Rule 6-2-3 and C++17 [[fallthrough]]; attribute

Wed, 27 Mar 2024 14:44:15 +0000

Should the C++17 [[fallthrough]]; attribute be given an exception for MISRA C++ 2008 Rule 6-2-3 (a null statement shall appear on a line by itself)?

Rule 6-3-1: Does it also apply to "case" blocks?

Thu, 24 Aug 2023 12:05:46 +0000

Consider this piece of code:

Code:
enum Foo

{

  a,

  b

};

void foo(Foo f)

{

  switch(f)

  {

    case a:

      std::cout << "a\n";

      break;

    case b:

      std::cout << "b\n";

      break;

  }

}

Is the above compliant with M6-3-1, or does one need to add braces also to the "case" blocks, e.g.:

Code:
case a:

{

  std::cout << "a\n";

  break;

}

Thanks!

Rule 6-5-2: Non-Compliant Example Clarification

Thu, 09 Feb 2023 17:36:03 +0000

I am looking for some clarification on the first non-compliant example for Rule 6-5-2, and the overall definition of a loop-counter, which as part of its definition states it must be,

Quote:an operand to a relational operator in condition

Where relational operator is defined in Rule 4-5-2, 4-5-3, and §5.9 as <, >, <=, and >=.

In the non-compliant example

Code:
for ( i = 1; i != 10; i += 2 ) // Non-compliant

The variable i is clearly considered a loop-counter because the subject of Rule 6-5-2 is a loop-counter. I am confused as to how could i could be considered a loop-counter though, because it is not an operand to a relational operator in the for loop condition.

Moreover, if a loop-counter is defined as necessarily being an operand to a relational operator, then the point of Rule 6-5-2 is called into question. The only thing it could be applied to is when a variable is used as an operand to a relational operator (making it a loop-counter) and another expression in the conditions like,

Code:
for ( i = 1; i != 10 && i > 0 ; i += 2 ) // Non-compliant

Which is helpful for some bad behavior, but will clearly miss some fairly obvious bad behavior, like the original non-compliant example.

Tangentially related the definition of loop-counter contains a note explicitly saying that iterators are also valid as a loop-counter. However, this note would be odd, since typically when using STL iterators in loops equality operators are used and not relational operators. So Rule 6-5-1 would flag the following as non-compliant, even though it is a common idiom.

Code:
for (auto it = container.begin(); it != container.end(); ++it )

6-5-2 and 6-5-4 on while loop checking std::vector::empty()

Tue, 26 Oct 2021 12:14:14 +0000

Hi,

We have a static analyzer that is reporting warnings related to 6-5-2 and 6-5-4 in the following code:

Code:
    std::vector v{};

    // Fill vector

    // ...

    // Consume vector

    while (!v.empty())  // <<< 6-5-2, 6-5-4 violated here?

    {

        std::int32_t const value{v.back()};

        v.pop_back();

        std::cout << value << "\n";

    }

The warning is that the "loop counter v" is not compared against a relational operator (6-5-2) nor is it modified via ++ et al. (6-5-4).

The static analysis tool vendor claims this is not a false positive and indeed it's required by the MISRA rules.

Could you shed some light as to whether the code above is violating 6-5-2 and 6-5-4? Is "v" really a loop counter as per the MISRA definition? One could argue that the loop counter is the private member std::vector::__size, but is that really the scope of this rule?

This code pattern is very typical when implementing e.g. graph search, having a list of Nodes and inspecting them one by one until a condition is reached or the list of nodes is empty. The list of nodes can typically grow while inspecting each node, so iterator-based searches are not a good implementation alternative.

Comments are needed for Rule 6-4-2? and should be placed inside the "else" block?

Fri, 02 Apr 2021 03:02:49 +0000

Hi,

With regards to Rule 6-4-2

Quote:All if … else if constructs shall be terminated with an
else clause.

we have some different interpretations, so could you kindly help clarify the following questions for us:
1. The rule only talks about "if … else if constructs shall be terminated with an else clause." in the title, and doesn't mention anything about adding necessary comments for the else clause in the title. However, in the rationale part, it indeed mentions that the final else statement should "either take appropriate action or contain a suitable comment", the question is: shall we take the rationale part into account to interpret this rule, more specifically, is the following code snippet compliant?

Code:
if ( x < 0 )

{

log_error ( 3 );

x = 0;

}

else if ( y < 0 )

{

x = 3;

}

else

{

}

2. If the comments are necessary, where shall it be placed: right in the else block? or any places around the else clause, for example, are the following cases compliant?

Code:
if ( x < 0 )

{

log_error ( 3 );

x = 0;

}

else if ( y < 0 )

{

x = 3;

}

// No change in value of x

else

{

}

Code:
if ( x < 0 )

{

log_error ( 3 );

x = 0;

}

else if ( y < 0 )

{

x = 3;

}

else // No change in value of x

{

}

Code:
if ( x < 0 )

{

log_error ( 3 );

x = 0;

}

else if ( y < 0 )

{

x = 3;

}

else

// No change in value of x

{

}

Many thanks in advance!

6-5-4: on variable or expression?

Fri, 29 Jan 2021 11:06:51 +0000

Hello,

6-5-4 says "The loop-counter shall be modified by one of: --, ++, - = n, or + = n; where n remains constant for the duration of the loop"

Should this code below raise 6-5-4?

int main() {
int k = 8;

for (int j = 0; j < 10; j += k + 3) {
}
}

If 'n' concerns variable only, I would say 'Yes'.
If 'n' concerns expressions, I would say 'No'.

What do you think?
Thanks in advance for your help.

Nadège

Rule 6-6-3 in while-loops

Tue, 29 Oct 2019 07:00:26 +0000

Dear MISRA members,

Regarding the rule 6-6-3:
Does this rule only apply to for-loops or does it also apply to while-loops?

For references, the static analysis tool, Coverity reports a 6-6-3 rule violation when 'continue' statement is used in a while-loop.

Best Regards,
Goh

Gotos in switches and Rule 6-4-5

Fri, 01 Mar 2019 17:39:27 +0000

Consider the following example:

Code:
typedef unsigned short uint16_t;

uint16_t foo(uint16_t x) {

    switch(x) {

        case 1:

            { goto end; }

        case 2:

            ++x;

            break;

        default:

            break;

    }   

end:

    ++x;

    return x;

}

The first case containing the goto appears to violate rule 6-4-5 which states that a case must end in a break or throw statement. If a break is added anywhere after the goto, it will be unreachable and would seemingly violate Rule 0-1-1 which forbids unreachable code. Rule 6-4-3 seems to consider the use of goto in a switch as it says that jump-statements (which includes goto) "are permitted within the compound statements forming the body of a switch-clause". Is it intended that an unconditional goto in a switch will require a deviation from either 6-4-5 or 0-1-1?

Chapter 6.6.5 Iteration statements

Fri, 06 Jul 2018 11:03:25 +0000

Hello,

Regarding the rules 6-5-1, 6-5-2, 6-5-3, 6-5-4, 6-5-5, 6-5-6:
Do these rules only apply to for-loops or do they also apply to while-loops?

best regards,
Stefan

Rule 6-2-1 Assignment operators shall not be used in subexpressions

Wed, 30 May 2018 12:44:49 +0000

Hello.

Why are the following MISRA Example compliant?
Is not a sub-expression?

Code:
if ( int16_t i = foo ( ) ) // Compliant

{

}

It looks like the following, but the following are non-compliant.
What are the differences?

Code:
if ( x = y ) // Non-compliant

{

ã€€foo ( );

}

Rule 6-6-5 A function shall have a single point of exit at the end of function.

Thu, 19 Apr 2018 16:24:41 +0000

Hello,

We are interested about id 0000023 but in C++.

We would like to be MISRA compatible.
But forbid multiple return in some case make the code less understandable.
Further more with the use of RAII, it is pretty safe to have multiple return inside a function.
This rule inherited from C where multiple return is highly unsafe is about to evolve in new version of MISRA C++ ?
If not, this is a "Required" rules, could it be added to a "deviation permits" ?

Example:
If we transform this code using "early return pattern" method which is not MISRA on rule 6-6-5.

Code:
int CheckIsOk()

{

if (currentObject == NULL)

{

    return E_ERR_1;

}

if (!IsClassValid(id))

{

    return E_ERR_2;

}

currentObject->test();

return E_OK;

}

into MISRA

Code:
int CheckIsOk()

{

int err = E_OK;

if (err == E_OK && currentObject == NULL)

{

    err = E_ERR_1;

}

if (err == E_OK && !IsClassValid(id))

{

    err = E_ERR_2;

}

currentObject->test(); // Developer miss to add "err == E_OK && "

return err;

}

If you miss to add a test somewhere like for testing "again" currentObject before to use it, you'll get a possible crash....
It increase complexity of code and make it unsecured.
Readability is something very important to get trusty code.

You can also transform it to another form

Code:
int CheckIsOk()

{

    int err = E_OK;

    if (currentObject)

    {

        if (IsClassValid(id))

        {

            currentObject->test();

        }

        else

        {

            err = E_ERR_2;

        }

    }

    else

    {

        err = E_ERR_1;

    }

    // "Difficulties" to add code here

    if( err == E_OK)

    {

        // Do something

    }

    return err;

}

But the readability is less good than "early return pattern", because you "jump" from "if" to "if" and the last part to execute some code is subject to errors (or after any else), if no test are added before the return statement to test the error state.

ps:
In MISRA 2008 document chapter 6-6-5, there is a synthax mistake on fn3, there is missing {}

For Loop: must update expression use only invariants?

Wed, 29 Nov 2017 15:47:10 +0000

MISRA C:2012 Rule 14.2 puts the following restriction on the "third clause" (called "expression" in C++:2008):

Shall not use objects that are modified in the for loop body.

For example, the following violates this rule:
[code]
for (int i=0; i