MISRA Discussion Forums - All Forums

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?

It 8.12 intended to be so strict?

Thu, 25 Jun 2026 22:05:26 +0000

Hello,

It is clear by looking at the title of rule 8.12

Quote:Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique

That the following code is non-compliant:

Code:
// Non-compliant, yellow has an implixitly defined value that it shares with last

enum colour { red, blue, green, yellow, last = yellow };

This is a relatively common pattern, and the alternatives seem worse.

It is the intent of this rule to prevent this pattern, or is it just a result of the wording?
By the way, this code is compliant with the C++ version of this rule in MISRA C++:2023.

10.3 Clarify if narrower in the title refers the the rank of the essential type

Thu, 25 Jun 2026 21:03:44 +0000

The rule 10.3 says:

Quote:The value of an expression shall not be assigned to an object with a narrower //essential type//

What does it mean to be narrower? To have a lower rank, or to have a smaller size?

For instance, on a platform where

Code:
sizeof(long) == sizeof(long long)

Is the following code compliant with rule 10.3:

Code:
long l = 0;

long long ll = 0;

l = ll; // Compliant or not?

My feeling is that it is compliant, because the word rank is not used here, while it is explicitly used in other parts of the rule, but I'm not 100% confident.

What is the UTLR of -1?

Tue, 09 Jun 2026 09:36:31 +0000

I'm attempting to determine the essential type of the following expression:

Code:
(unsigned short)1 - (unsigned short)2

This is a operation subject to arithmetic conversion (D.7.9), both operands are essentially unsigned, and the expression is an integer constant expression, so according to item 4.1, the essential type of the result is the UTLR of the result.

However, the result is a signed integer with the value -1. The following program demonstrates this:

Code:
#include 

#define TYPE(x) _Generic((x), \

    int: printf("int\n"), \

    unsigned int: printf("unsigned int\n"), \

    default: printf("other\n") \

)

int main() {

    TYPE(1u - 2u);  

    TYPE(1 - 2);  

    TYPE((unsigned short)1 - (unsigned short)2);

}

So we have to compute the UTLR of a negative value, which is not defined.

Is there an error in my reasoning, or is this a limitation in the essential type system?

13.2 Was TC2 correctly applied to the rule in MISRA C:2023?

Wed, 03 Jun 2026 15:27:35 +0000

Hello,

TC2 says:

Quote:TC 2.23 : In the “Amplification” section, number the existing two notes as 1 and 3 respectively.
TC 2.24 : In the “Amplification” section, insert a new note 2 between the existing two notes: 2. All parts of the expression are considered when determining whether an object is read or modified, irrespective of any known values

But when looking at MISRA C:2023, we only see 2 notes, and the text that was supposed to be inserted as node 2 appears in second position in the bullet list above the notes.

Which is right? The TC2, or the 2023 version?

Thank you,

Rule 6.5.2: Missing exception for static class members?

Tue, 02 Jun 2026 07:14:08 +0000

The wording of rule 6.5.2 seems to imply that any entity with internal linkage may not be declared static, even though the static keyword “also has other uses”.
With that interpretation, the rule would completely prohibit the use of static class members with internal linkage.

For example, given this code snippet:

Code:
static void F1() {} // 1

namespace {

static void F2() {} // 2

class Klass {

  public:

    static void F3() {} // 3

};

} // namespace

In cases 1 and 2, the static keyword is “inappropriate”. F1 should be declared inside the anonymous namespace instead and for F2 the static keyword could be simply dropped.
F3 has internal linkage but the static is not used for linkage but to make the function a class function. Still, the amplification of rule 6.5.2 says that internal linkage of an entity is only appropriate if it’s not declared static, which F3 clearly is.

Is that intentional? Should the wording be improved to make it clear that only static declarations which could affect linkage are considered?
Or (to simplify static analysis) could an exception be added for static class members?