MISRA Discussion Forums - Portal

Rule 0.1.1 Example f4

Wed, 30 Sep 2026 12:05:20 +0000

Hi,

In MISRA C++:2023 TC1 Rule 0.1.1, the comment about example f4() says:

As j is only incremented, no value is overwritten without first being read. Additionally, all iterations
of the loop other than the first observe j after it has been incremented, meaning the write in the
increment is necessary.

This is not technically correct: the *last* iteration of the loop will *not* observe the value of j after it has been incremented. Do you consider that the last increment of "j" violates Rule 0.1.1?

What about this?

Code:
template 

void f()

{

  int j = 0;

  for (int i = 0; i < n; ++i)

  {

    use(j);

    j++;  // Violates Rule 0.1.1 for n == 1?

  }

}

The above code never uses the incremented value of "j" for a template instantiation with "n = 1". Is that a violation of Rule 0.1.1?

I see now that this exact use case was explicitly allowed in the original MISRA C++:2023 document, but removed in the TC1.

Code:
Within a loop, a value may be written to an object with the intent that it will be observed during the

next iteration, meaning that the value written on the last iteration may never be observed. Whilst it is

possible to restructure the loop to avoid this behaviour, there is a risk that the resulting code may be

of lower quality (less clear, for example). This rule therefore considers observation during any iteration

to apply to all values written to such an object, including a value written during the last iteration of a

loop that is not actually observed — see example f3, below.

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.

M5-0-4 switch over unscoped enum without fixed underlying type

Wed, 16 Sep 2026 11:08:53 +0000

Hi,

Our static analyzer is flagging this code:

Code:
// third_party.h

typedef enum 

{

  FOO_A,

  FOO_B

} Foo;

// main.cpp

#include 

int get(Foo x)

{

  switch(x)            // Non-compliant with M5-0-4 ?

  {

    case FOO_A:        // Non-compliant with M5-0-4 ?

      return 123;

    case FOO_B:        // Non-compliant with M5-0-4 ?

      return 321;

  }

  return -1;

}

The rationale from the supplier is:

"Foo" is an unscoped enum without fixed underlying type.
Thus, its underlying type is implementation-defined.
On this implementation, the actual type is "unsigned int".
The line with "switch(x)" performs an integral promotion of "x" to "int", thus changing the signedness from "unsigned int" to "int".
Similarly, the "case FOO_*" lines also perform an integral promotion to "int".
This change in signedness is a violation of M5-0-4.

We argue however that the code is perfectly safe and idiomatic, the Standard guarantees that the conversion is made to an integer able to hold all the values of the enumerator, so it's impossible for data loss to occur.

What is your opinion, is M5-0-4 truly applicable in this case?

Thanks!

Rule 8-4-4 Exception for stream manipulators?

Mon, 07 Sep 2026 08:22:54 +0000

Hi,

Does Rule 8-4-4 imply that we have to write code like this? I do not see any exception for stream manipulators. Our static analyzer is flagging this case.

Code:
std::cout << "Hello World" << &std::endl;

                              ^

13.3 Should side effects be allowed in comma expressions?

Mon, 31 Aug 2026 12:52:23 +0000

In a comma expression (which is discouraged by another advisory rule, 12.3, but could still be used), there is a clear separation in term of execution between what comes before and what comes after the comma. Therefore, I think the rationale is not very strong in this case.

What would you think of relaxing 13.3 and making this example compliant (it would still be non-compliant with 12.3):

Code:
int f(int n, int*dest) {

    for (int i = 0 ; i<10 ; ++i, ++dest) { // Currently non-compliant

        *dest = i*i;

    }

}

13.3 What not being evaluated means?

Fri, 28 Aug 2026 16:19:16 +0000

Hi there,

Rule 13.3 says:

Quote:All sub-expressions of the full expression are treated as if they were evaluated for the purposes of this rule, even if specified as not being evaluated by the C Standard.

I understand what it makes sense in the context for instance of the conditional operator, but I wanted to check it this applies the sub-expressions that can be determined as never evaluated because they are in non-evaluated operands.

Code:
int f(int a) {

    volatile int i;

    return ++a + sizeof(i); 

}

Accessing the volatile variable i is a persistent side effect, but since this access happens as part of a sizeof operand, that is not evaluated, no actual access to the volatile actually happens.

Would it make sense to update this rule (and several other that use similar wording) to separate the undecidable case of infeasible paths from the very decidable case of non-evaluated expressions?

FYI, in similar cases, MISRA C++ uses wording such as " even if they occur in an infeasible path" instead of "even if specified as not being evaluated".

Clarification Rule 0.2.1

Thu, 27 Aug 2026 11:32:03 +0000

Hi,

I have a question regarding rule 0.2.1 on the following code:

Code:
namespace {

struct Base {

  Base() {

    // do resource management

  }

};

struct Derived : public Base {

  // has implicit default constructor that calls user-provided Base()

};

Base b; // (1) compliant

Derived d; // (2) compliant or non-compliant for rule 0.2.1 ?

}

Case (1) is clearly compliant as b has class type Base and Base has a user-provided constructor.
Case (2) is unclear, as the default constructor of Derived is not user-provided, if I understand the C++ standard correctly, as the user does not declare it at all.
Still case (2) seems fine and in line with the rule's rationale.

It would be great to get a clarification whether case (2) is considered compliant or not, and if compliant, what the intended definition of "use" should be.
Thanks a lot!

20.12 Does the stringification really matter?

Tue, 07 Jul 2026 09:59:02 +0000

Hello,

While looking at violations of 20.12 A macro parameter used as an operand to the "#" or "##" operators, which is itself subject to further macro replacement, shall only be used as an operand to these operators, I discovered that most of them were of the form:

Code:
assert(value < LIMIT)

Indeed, the macro parameter of assert is typically stringified, and in that case it contains the macro LIMIT that is itself subject to further replacement.

However, I don't see the safety case for this violation. The fact that the unexpended version of the macro will appear in the string is exactly what is needed.

I agree that with token pasting (##), this situation could lead to hard to understand code, but not with stringification.

FWIW, I discussed this with MISRA C++ (that contains the same rule), and the sentiment of the group was that the rule should be updated to remove the stringification part.

What do you think?

Does rule A2-10-5 apply to reusing an external identifier as a member identifier?

Mon, 06 Jul 2026 12:23:34 +0000

Rule A2-10-5 states: Regardless of scope, no identifier with static storage duration should be reused across any source files in the project. Are cases where an identifier is reused as a member non-compliant with this rule? In particular, the case where an operator function is defined as a global and a member function.

Code:
struct S

{

  void operator<<(S&) {}

  void f1(int par) {}

};

namespace N

{

  void operator<<(int i, S&) {}  // Is compliant or non-compliant?

  void f1(int par) {}            // Is compliant or non-compliant?

}

Is Fn4 example in AUTOSAR rule A7-5-2 correct?

Thu, 02 Jul 2026 10:49:49 +0000

AUTOSAR rule A7-5-2 has the following example:

Code:
std::int32_t Fn4(std::int32_t number) 

{ 

  if (number == 1) 

  {

    number = number * Fn3(number - 1);  // Non-compliant 

  }   

  return number; 

}

Fn3 is a recursive function and thus non-compliant. Fn4 is making a call to Fn3. However, in this line, the function is not calling itself. Why is this line Non-compliant? Is this an issue with the example?