<![CDATA[MISRA Discussion Forums - 4.0 Language independent issues]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 13:03:25 +0000 MyBB <![CDATA[Rule 0.1.1 Example f4]]> https://forum.misra.org.uk/showthread.php?tid=1787 Wed, 30 Sep 2026 12:05:20 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1787
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 <int n>
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.
]]>
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 <int n>
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.
]]> <![CDATA[Clarification Rule 0.2.1]]> https://forum.misra.org.uk/showthread.php?tid=1779 Thu, 27 Aug 2026 11:32:03 +0000 hahn]]> https://forum.misra.org.uk/showthread.php?tid=1779
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!]]>
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!]]> <![CDATA[Rule 0.1.2 - missing exceptions and advisory ?]]> https://forum.misra.org.uk/showthread.php?tid=1746 Thu, 07 Aug 2025 22:07:31 +0000 kth]]> https://forum.misra.org.uk/showthread.php?tid=1746
The amplification of MISRA C++:2023 rule 0.1.2 states that “This rule only applies when the function is called explicitly using function call syntax”.
Consequently, operators like “+=” are out of scope so in the following code the modification of the std:Confusedtring object with “+=” is fine and the usage of append, without checking the returned reference, is a violation of this required rule:
Code:
void example1() {
    // Non-compliant use of std::string::append
    std::string my_string;
    my_string.append("foo");  // add 'foo'
    my_string.append("bar");  // add 'bar'
}

void example2() {
    // Compliant use of std::string::operator+=:
    std::string my_string;
    my_string += "foo";  // add 'foo'
    my_string += "bar";  // add 'bar'
}

void example3() {
    std::vector<int> numbers;

    numbers.push_back(1);  // Compliant to MISRA C++:2023 Rule 0.1.2
                           // as push_back ""returns"" void

    // C++ reference: https://en.cppreference.com/w/cpp/container/vector/push_back.html

    // emplace_back returns (since C++17) an iterator:
    // https://en.cppreference.com/w/cpp/container/vector/emplace_back.html

    numbers.emplace_back(2);  // Non-compliant to MISRA C++:2023 Rule 0.1.2 (since C++17)
}

The function append of std:Confusedtring (std::basic_string) and the operator+= append additional characters to the end of the string. Both return a reference to “*this”. Both throw std::length_error if the operation would cause size() to exceed max_size() and provide the strong exception safety guarantee. So, there is no real difference between using “+=” or “append” in terms of safety or code quality. If one wants to write compliant code, example1 needs to be refactored to use a void cast  to ignore the result:

Code:
void example1_compliant_version() {
    std::string my_string;
    static_cast<void>(my_string.append("foo"));  // add 'foo'
    static_cast<void>(my_string.append("bar"));  // add 'bar'
}

That would implicitly force developers to always prefer operators like “+=” over functions like “append” as the alternatives make the code harder to read or lead to additional effort (deviations need to be justified).

If one decides to rework this kind of code to a “fluent API style” that could lead to extra copies:
Code:
std::string BuildFailureMsg(std::string_view name, std::string_view reason) {
    std::string msg{};
    msg.reserve(name.size() + reason.size() + 26);  // reserve sufficient memory
    msg.append("Component ");
    msg.append(name);
    msg.append(" failed due to ");
    msg.append(reason);
    msg.append("\n");
    return msg;
}
std::string BuildFailureMsgNaiveRefactor(std::string_view name,
                                      std::string_view reason) {
    std::string msg{};
    msg.reserve(name.size() + reason.size() + 26);  // reserve sufficient memory
    return msg.append("Component ")
        .append(name)
        .append(" failed due to ")
        .append(reason)
        .append("\n"); // will create and return copy of msg (i.e. see extra "memcpy")
}
int main() {
    std::string failure_msg_01 = BuildFailureMsg("Logger", "insufficient memory");  // no copies/moves
    std::string failure_msg_02 = BuildFailureMsgNaiveRefactor("Logger", "insufficient memory");  // extra copy
}

Consequently, existing code that uses append needs to be refactored to use “+=”. A huge refactoring effort for large code bases, but without any real benefit.
Also, it might lead to the negative effect that developers that uses std::vector prefer “push_back” over “emplace_back”, as with C++17 std::vector::emplace_back returns a reference (example3). Other alternatives might lead to less efficient code. 

Our questions:
  1.       Is it really intended to promote the usage of operators over functions and (for std::vector and other std-library types like std::optional::emplace) to use push_back over emplace_back or are here just exceptions missing?
  2. As the rationale states that “it is possible to call a function without using the return value, which may be an error”, should this rule be changed to “advisory” and the title changed to “The value returned by a function should be used”.
  3. Independent of 1 and 2: should an additional exception for functions that use C++ exceptions to report errors added?
]]>
The amplification of MISRA C++:2023 rule 0.1.2 states that “This rule only applies when the function is called explicitly using function call syntax”.
Consequently, operators like “+=” are out of scope so in the following code the modification of the std:Confusedtring object with “+=” is fine and the usage of append, without checking the returned reference, is a violation of this required rule:
Code:
void example1() {
    // Non-compliant use of std::string::append
    std::string my_string;
    my_string.append("foo");  // add 'foo'
    my_string.append("bar");  // add 'bar'
}

void example2() {
    // Compliant use of std::string::operator+=:
    std::string my_string;
    my_string += "foo";  // add 'foo'
    my_string += "bar";  // add 'bar'
}

void example3() {
    std::vector<int> numbers;

    numbers.push_back(1);  // Compliant to MISRA C++:2023 Rule 0.1.2
                           // as push_back ""returns"" void

    // C++ reference: https://en.cppreference.com/w/cpp/container/vector/push_back.html

    // emplace_back returns (since C++17) an iterator:
    // https://en.cppreference.com/w/cpp/container/vector/emplace_back.html

    numbers.emplace_back(2);  // Non-compliant to MISRA C++:2023 Rule 0.1.2 (since C++17)
}

The function append of std:Confusedtring (std::basic_string) and the operator+= append additional characters to the end of the string. Both return a reference to “*this”. Both throw std::length_error if the operation would cause size() to exceed max_size() and provide the strong exception safety guarantee. So, there is no real difference between using “+=” or “append” in terms of safety or code quality. If one wants to write compliant code, example1 needs to be refactored to use a void cast  to ignore the result:

Code:
void example1_compliant_version() {
    std::string my_string;
    static_cast<void>(my_string.append("foo"));  // add 'foo'
    static_cast<void>(my_string.append("bar"));  // add 'bar'
}

That would implicitly force developers to always prefer operators like “+=” over functions like “append” as the alternatives make the code harder to read or lead to additional effort (deviations need to be justified).

If one decides to rework this kind of code to a “fluent API style” that could lead to extra copies:
Code:
std::string BuildFailureMsg(std::string_view name, std::string_view reason) {
    std::string msg{};
    msg.reserve(name.size() + reason.size() + 26);  // reserve sufficient memory
    msg.append("Component ");
    msg.append(name);
    msg.append(" failed due to ");
    msg.append(reason);
    msg.append("\n");
    return msg;
}
std::string BuildFailureMsgNaiveRefactor(std::string_view name,
                                      std::string_view reason) {
    std::string msg{};
    msg.reserve(name.size() + reason.size() + 26);  // reserve sufficient memory
    return msg.append("Component ")
        .append(name)
        .append(" failed due to ")
        .append(reason)
        .append("\n"); // will create and return copy of msg (i.e. see extra "memcpy")
}
int main() {
    std::string failure_msg_01 = BuildFailureMsg("Logger", "insufficient memory");  // no copies/moves
    std::string failure_msg_02 = BuildFailureMsgNaiveRefactor("Logger", "insufficient memory");  // extra copy
}

Consequently, existing code that uses append needs to be refactored to use “+=”. A huge refactoring effort for large code bases, but without any real benefit.
Also, it might lead to the negative effect that developers that uses std::vector prefer “push_back” over “emplace_back”, as with C++17 std::vector::emplace_back returns a reference (example3). Other alternatives might lead to less efficient code. 

Our questions:
  1.       Is it really intended to promote the usage of operators over functions and (for std::vector and other std-library types like std::optional::emplace) to use push_back over emplace_back or are here just exceptions missing?
  2. As the rationale states that “it is possible to call a function without using the return value, which may be an error”, should this rule be changed to “advisory” and the title changed to “The value returned by a function should be used”.
  3. Independent of 1 and 2: should an additional exception for functions that use C++ exceptions to report errors added?
]]> <![CDATA[Rule 0.1.1]]> https://forum.misra.org.uk/showthread.php?tid=1741 Mon, 30 Jun 2025 12:59:47 +0000 Merge]]> https://forum.misra.org.uk/showthread.php?tid=1741
I was made aware of the following by a colleague.
In one of the official examples for rule 0.1.1 MISRA C++ 2023 states, quote:
Code:
m = 10; // Non-compliant - when looping, overwrites incremented value

However, I would argue that during the last loop iteration, the value is being read (and modified) by the increment before being returned. In the rule amplification, it is stated that an object is considered observed if it has been observed in any iteration, which I would therefore consider being the case here.

In other words, `m` is observed in this line, so it should not be a violation as per the rule amplification. Am I missing something?

I'll admit that the example is not the cleanest code for expressing the particular functionality (e.g., statement could be moved out of the loop), but we have to keep in mind that this is merely a simple example for illustration purposes and a real-world example might look comparatively more complex.

I would appreciate a second opinion :-)

Best regards,
Daniel "Merge" Merget]]>
I was made aware of the following by a colleague.
In one of the official examples for rule 0.1.1 MISRA C++ 2023 states, quote:
Code:
m = 10; // Non-compliant - when looping, overwrites incremented value

However, I would argue that during the last loop iteration, the value is being read (and modified) by the increment before being returned. In the rule amplification, it is stated that an object is considered observed if it has been observed in any iteration, which I would therefore consider being the case here.

In other words, `m` is observed in this line, so it should not be a violation as per the rule amplification. Am I missing something?

I'll admit that the example is not the cleanest code for expressing the particular functionality (e.g., statement could be moved out of the loop), but we have to keep in mind that this is merely a simple example for illustration purposes and a real-world example might look comparatively more complex.

I would appreciate a second opinion :-)

Best regards,
Daniel "Merge" Merget]]> <![CDATA[Rule 0.1.2]]> https://forum.misra.org.uk/showthread.php?tid=1715 Thu, 21 Nov 2024 13:12:46 +0000 stephanmuench]]> https://forum.misra.org.uk/showthread.php?tid=1715
I would have a question about MISRA C++:2023 Rule 0.1.2 which mentions in its rationale
"Overloaded operators are excluded from this rule because [...]"

Here, my question is whether in this scope, `operator()` should be considered to be a built-in operator.
Since to me, such one should instead be considered more of a normal function call.
Otherwise, it would undermine the rule's actual intention, which is to diagnose any unused return values of function calls, am I right?
Especially for modern C++ where plenty of code gets put into lambdas and/or std::function.

I would very happy if you could share some thoughts about this.

Thanks a lot in advance & best regards,
Stephan]]>
I would have a question about MISRA C++:2023 Rule 0.1.2 which mentions in its rationale
"Overloaded operators are excluded from this rule because [...]"

Here, my question is whether in this scope, `operator()` should be considered to be a built-in operator.
Since to me, such one should instead be considered more of a normal function call.
Otherwise, it would undermine the rule's actual intention, which is to diagnose any unused return values of function calls, am I right?
Especially for modern C++ where plenty of code gets put into lambdas and/or std::function.

I would very happy if you could share some thoughts about this.

Thanks a lot in advance & best regards,
Stephan]]> <![CDATA[Rule 0.0.1]]> https://forum.misra.org.uk/showthread.php?tid=1686 Fri, 24 May 2024 05:20:55 +0000 gdavis]]> https://forum.misra.org.uk/showthread.php?tid=1686
I apologize for this basic question, but can somebody please walk me through the first first five lines of MISRA C++ 2023 Rule 0.0.1?

bool f0();

int32_t f1( int32_t c, int32_t &res )
{
  if ( false && f0() ) { }       // Compliant - statement is considered to be reachable
  ...

In particular, why is the empty block statement ("{ }") considered to be reachable? My thinking is:

The condition of the if statement is considered a constant expression in C++17, one that evaluates to false. Therefore, we follow the third bullet point:
  • The blocks linked by the edges from a condition of a selection-statement or an iteration-statement are all considered reachable, except when the condition is a constant expression, in which case only the blocks linked by edges selected by the condition are considered reachable.

So, this seems to me that we should consider the empty block statement to be unreachable.

Also, what is the purpose of the first two bullet points:
  • Both operands of a reachable logical AND (&&) or logical OR (||) operator are considered reachable
  • All three operands of a reachable conditional operator ( ? : ) are considered reachable

Rule 0.0.1 is concerned with statements, so I don't see how subexpressions matter unless these rules are meant to convey that an expression such as ( false && f0() ) is potentially throwing and/or not a constant expression (for the purposes of this rule).. But, I feel like I may be reading too much into this.

Thank you in advance.]]>
I apologize for this basic question, but can somebody please walk me through the first first five lines of MISRA C++ 2023 Rule 0.0.1?

bool f0();

int32_t f1( int32_t c, int32_t &res )
{
  if ( false && f0() ) { }       // Compliant - statement is considered to be reachable
  ...

In particular, why is the empty block statement ("{ }") considered to be reachable? My thinking is:

The condition of the if statement is considered a constant expression in C++17, one that evaluates to false. Therefore, we follow the third bullet point:
  • The blocks linked by the edges from a condition of a selection-statement or an iteration-statement are all considered reachable, except when the condition is a constant expression, in which case only the blocks linked by edges selected by the condition are considered reachable.

So, this seems to me that we should consider the empty block statement to be unreachable.

Also, what is the purpose of the first two bullet points:
  • Both operands of a reachable logical AND (&&) or logical OR (||) operator are considered reachable
  • All three operands of a reachable conditional operator ( ? : ) are considered reachable

Rule 0.0.1 is concerned with statements, so I don't see how subexpressions matter unless these rules are meant to convey that an expression such as ( false && f0() ) is potentially throwing and/or not a constant expression (for the purposes of this rule).. But, I feel like I may be reading too much into this.

Thank you in advance.]]> <![CDATA[Rule 0.2.4 non-compliant reason]]> https://forum.misra.org.uk/showthread.php?tid=1676 Fri, 15 Mar 2024 14:20:50 +0000 danix800]]> https://forum.misra.org.uk/showthread.php?tid=1676
Hi! I've questions about the examples of MISRA C++:2023 Rule 0.2.4 "Functions with limited visibility should be used at least once":

namespace B
{
  struct C2 {};
  static void swap( C2 &, C2 & ); // Non-compliant
}

B:Confusedwap() is marked as non-compliant, could anyone please give some explanations?

Thank you very much!]]>
Hi! I've questions about the examples of MISRA C++:2023 Rule 0.2.4 "Functions with limited visibility should be used at least once":

namespace B
{
  struct C2 {};
  static void swap( C2 &, C2 & ); // Non-compliant
}

B:Confusedwap() is marked as non-compliant, could anyone please give some explanations?

Thank you very much!]]>