<![CDATA[MISRA Discussion Forums - AUTOSAR C++:2014 rules]]> https://forum.misra.org.uk/ Mon, 09 Nov 2026 19:53:38 +0000 MyBB <![CDATA[Does rule A2-10-5 apply to reusing an external identifier as a member identifier?]]> https://forum.misra.org.uk/showthread.php?tid=1777 Mon, 06 Jul 2026 12:23:34 +0000 mstaron]]> https://forum.misra.org.uk/showthread.php?tid=1777
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?
}
]]>
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?
}
]]> <![CDATA[Is Fn4 example in AUTOSAR rule A7-5-2 correct?]]> https://forum.misra.org.uk/showthread.php?tid=1776 Thu, 02 Jul 2026 10:49:49 +0000 limdor]]> https://forum.misra.org.uk/showthread.php?tid=1776 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?]]> 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?]]> <![CDATA[AUTOSAR C++14 M5-2-10 for unique_ptr in combination with ++ operator]]> https://forum.misra.org.uk/showthread.php?tid=1769 Fri, 08 May 2026 08:51:28 +0000 kth]]> https://forum.misra.org.uk/showthread.php?tid=1769
Quote:Rule M5-2-10 (required, implementation, automated)
The increment (++) and decrement ( ) operators shall not be mixed with other operators in an expression.

There is a similar MISRA C:2012/2023/2025 rule 
Quote:Rule 13.3 A full expression containing an increment (++) or decrement (--) operator should have no other potential side effects other than that caused by the increment or decrement operator

Also some examples are shared:
Code:
u8a = ++u8b + u8c--;  // Non-compliant
// The following sequence is clearer and therefore safer:
++u8b;
u8a = u8b + u8c;
u8c--;


While this makes makes sense for C and C++, there are differences between C and C. What about the following code:

Code:
#include <cstdint>
#include <memory>


struct Data {
        std::int32_t member;
};

std::int32_t main(){
        std::unique_ptr<Data> d = std::make_unique<Data>(12);
        d->member++;  // Compliant ?
}

Shall a AUTOSAR C++14/MISRA C++:2008 checker report a violation for  "d->member++" or is that OK?]]>
Quote:Rule M5-2-10 (required, implementation, automated)
The increment (++) and decrement ( ) operators shall not be mixed with other operators in an expression.

There is a similar MISRA C:2012/2023/2025 rule 
Quote:Rule 13.3 A full expression containing an increment (++) or decrement (--) operator should have no other potential side effects other than that caused by the increment or decrement operator

Also some examples are shared:
Code:
u8a = ++u8b + u8c--;  // Non-compliant
// The following sequence is clearer and therefore safer:
++u8b;
u8a = u8b + u8c;
u8c--;


While this makes makes sense for C and C++, there are differences between C and C. What about the following code:

Code:
#include <cstdint>
#include <memory>


struct Data {
        std::int32_t member;
};

std::int32_t main(){
        std::unique_ptr<Data> d = std::make_unique<Data>(12);
        d->member++;  // Compliant ?
}

Shall a AUTOSAR C++14/MISRA C++:2008 checker report a violation for  "d->member++" or is that OK?]]> <![CDATA[A3-3-2 Contradictory examples?]]> https://forum.misra.org.uk/showthread.php?tid=1731 Mon, 17 Mar 2025 09:58:14 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1731
On line 31, we have a compliant example:
Code:
A instance{}; // Compliant - constant (value) initialization

However, on line 37 it's no longer compliant:

Code:
static A a{}; // Non-compliant - A’s default c’tor is not constexpr

There seems to be a contradiction here. Either the code is doing value initialization, or it's calling a constructor, but not both. Which one is it?

In other words, it seems like both examples are doing the same thing, so both should either be compliant or non-compliant. Would you agree?]]>
On line 31, we have a compliant example:
Code:
A instance{}; // Compliant - constant (value) initialization

However, on line 37 it's no longer compliant:

Code:
static A a{}; // Non-compliant - A’s default c’tor is not constexpr

There seems to be a contradiction here. Either the code is doing value initialization, or it's calling a constructor, but not both. Which one is it?

In other words, it seems like both examples are doing the same thing, so both should either be compliant or non-compliant. Would you agree?]]> <![CDATA[A8-4-5: Should have an exception for move constructors]]> https://forum.misra.org.uk/showthread.php?tid=1725 Wed, 05 Feb 2025 09:45:55 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1725
Code:
class B
{
public:
  B(B&& oth) : ptr(std::move(oth.ptr)) // Compliant
  {
     oth.ptr = nullptr;
  }
};

Do you agree that A8-4-5 should explicitly clarify that the rule does not apply to move constructors?]]>
Code:
class B
{
public:
  B(B&& oth) : ptr(std::move(oth.ptr)) // Compliant
  {
     oth.ptr = nullptr;
  }
};

Do you agree that A8-4-5 should explicitly clarify that the rule does not apply to move constructors?]]> <![CDATA[A7-2-1 Still relevant in C++14?]]> https://forum.misra.org.uk/showthread.php?tid=1724 Wed, 29 Jan 2025 10:03:31 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1724 not unspecified (nor undefined) to cast an integer to the enum type when it is not any of the enumerators, since the valid range for the enum is the range of the underlying type. 

Based on that, what would be the rationale for keeping A7-2-1 in the AUTOSAR C++14 rules?]]> not unspecified (nor undefined) to cast an integer to the enum type when it is not any of the enumerators, since the valid range for the enum is the range of the underlying type. 

Based on that, what would be the rationale for keeping A7-2-1 in the AUTOSAR C++14 rules?]]> <![CDATA[A18-9-4]]> https://forum.misra.org.uk/showthread.php?tid=1714 Tue, 15 Oct 2024 09:58:28 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1714
I wonder if this code example technically violates A18-9-4?

Code:
#include <memory>

struct Foo
{
    explicit Foo(int);
};

int main()
{
    int val{};
    auto x = std::make_unique<Foo>(val);
    ++val; // non-compliant?
}

Since internally, std::make_unique takes the input arguments as "Args&&..." and std::forward's them into the constructor of the class.

Thanks!]]>
I wonder if this code example technically violates A18-9-4?

Code:
#include <memory>

struct Foo
{
    explicit Foo(int);
};

int main()
{
    int val{};
    auto x = std::make_unique<Foo>(val);
    ++val; // non-compliant?
}

Since internally, std::make_unique takes the input arguments as "Args&&..." and std::forward's them into the constructor of the class.

Thanks!]]> <![CDATA[A8-4-5: are partial moves allowed?]]> https://forum.misra.org.uk/showthread.php?tid=1709 Tue, 01 Oct 2024 12:28:11 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1709
For example, consider the following snippet from Effective Modern C++ (Meyers), Item 25, page 169:

Code:
class Widget {
public:
   Widget(Widget&& rhs)
   : name(std::move(rhs.name)),
     p(std::move(rhs.p))
   { … }
   …

// rhs is rvalue reference
private:
   std::string name;
   std::shared_ptr<SomeDataStructure> p;
};
]]>
For example, consider the following snippet from Effective Modern C++ (Meyers), Item 25, page 169:

Code:
class Widget {
public:
   Widget(Widget&& rhs)
   : name(std::move(rhs.name)),
     p(std::move(rhs.p))
   { … }
   …

// rhs is rvalue reference
private:
   std::string name;
   std::shared_ptr<SomeDataStructure> p;
};
]]> <![CDATA[A27-0-1 Unclear scope of the rule]]> https://forum.misra.org.uk/showthread.php?tid=1697 Tue, 20 Aug 2024 10:36:06 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1697
Rule A27-0-1 says:

Rule A27-0-1 (required, implementation, non-automated)
Inputs from independent components shall be validated.

This is very abstract and vague:

* What is the definition of "independent components"?
* Validated, in what context? When doing what?

The rule is in the section "Input/output library", and the code examples of this rule only talk about string manipulation/formatting functions. Can we therefore assume that this rule is only concerned with validating input passed to string manipulation/formatting functions?

Thanks!]]>
Rule A27-0-1 says:

Rule A27-0-1 (required, implementation, non-automated)
Inputs from independent components shall be validated.

This is very abstract and vague:

* What is the definition of "independent components"?
* Validated, in what context? When doing what?

The rule is in the section "Input/output library", and the code examples of this rule only talk about string manipulation/formatting functions. Can we therefore assume that this rule is only concerned with validating input passed to string manipulation/formatting functions?

Thanks!]]> <![CDATA[A13-5-4 opposite operator clarification]]> https://forum.misra.org.uk/showthread.php?tid=1683 Fri, 26 Apr 2024 15:34:38 +0000 aromauld]]> https://forum.misra.org.uk/showthread.php?tid=1683
The referenced JSF guideline says (such as == and !=) which implies there are others, but there are no examples present other than "!= and ==". 

Presumably this includes relational operators, but it doesn't discuss how. This rule would seemingly imply that <= should be implemented using >=. But would this mean that it is considered non-compliant to implement it with operator >?


Code:
inline bool operator<=(const X& lhs, const X& rhs) { return !(lhs > rhs); }

Are relational operators allowed to call any other relational operators? Are there any other pairings that are considered opposites for this rule?]]>
The referenced JSF guideline says (such as == and !=) which implies there are others, but there are no examples present other than "!= and ==". 

Presumably this includes relational operators, but it doesn't discuss how. This rule would seemingly imply that <= should be implemented using >=. But would this mean that it is considered non-compliant to implement it with operator >?


Code:
inline bool operator<=(const X& lhs, const X& rhs) { return !(lhs > rhs); }

Are relational operators allowed to call any other relational operators? Are there any other pairings that are considered opposites for this rule?]]> <![CDATA[cvalue and constant integral expression in generic context]]> https://forum.misra.org.uk/showthread.php?tid=1675 Tue, 12 Mar 2024 12:17:35 +0000 gerbor]]> https://forum.misra.org.uk/showthread.php?tid=1675
Main Question: Is N, which is an integral constant expression, a cvalue as defined in MISRA C++:2008?


Code:
template <typename T, int N>
constexpr auto fun()
{
    constexpr auto v = T{N};
   
    return /* something */;
}


Question 2: Does the use of {} or () have any affect on whether N is a cvalue?

Question 3: Does it matter whether T is fundamental type or a class type? For example:

Code:
template <typename T>
struct CustomScalar final
{
    T val{};

    constexpr CustomScalar() = default;
    explicit constexpr CustomScalar(T x) : val{x} {}
};

int main()
{
    fun<CustomScalar<float>, 2>();
}
]]>
Main Question: Is N, which is an integral constant expression, a cvalue as defined in MISRA C++:2008?


Code:
template <typename T, int N>
constexpr auto fun()
{
    constexpr auto v = T{N};
   
    return /* something */;
}


Question 2: Does the use of {} or () have any affect on whether N is a cvalue?

Question 3: Does it matter whether T is fundamental type or a class type? For example:

Code:
template <typename T>
struct CustomScalar final
{
    T val{};

    constexpr CustomScalar() = default;
    explicit constexpr CustomScalar(T x) : val{x} {}
};

int main()
{
    fun<CustomScalar<float>, 2>();
}
]]> <![CDATA[A4-5-1 with overloading operator<<]]> https://forum.misra.org.uk/showthread.php?tid=1664 Tue, 07 Nov 2023 14:12:13 +0000 Jakob Klein]]> https://forum.misra.org.uk/showthread.php?tid=1664 Hi

A4-5-1 states:

Quote:Expressions with type enum or enum class shall not be used as operands to built-in and overloaded operators other than the subscript operator [ ], the assignment operator =, the equality operators == and ! =, the unary & operator, and the relational operators <, <=, >, >=.
My understanding of the rule is that confusion should be avoided when using the underlying type arithmetically.
My use-case is overloading operator<< for convenient logging and printing of an unscoped enum:


Code:
inline std::ostream& operator<<(std::ostream& os, MyEnum const& enum_value)
{
    switch (enum_value)
    {
        case MyEnum_Unknown:
        {
            return os << "Unknown";
        }
        case MyEnum_Val1:
        {
            return os << "Descriptive message... (MyEnum_Val1)";
        }//...
     }
}

Usage, where the warning is shown:
Code:
LOG_WARNING << "Could not perform action with " << enum_value;



So as long as the enum is not used in arithmetic context ie. bitwise operations (the enum is the left-hand operand) but with the streeam insertion operator I can not follow the rationale of the rule. Is this an oversight in the rule or is there a more specific reason behind this?]]> Hi

A4-5-1 states:

Quote:Expressions with type enum or enum class shall not be used as operands to built-in and overloaded operators other than the subscript operator [ ], the assignment operator =, the equality operators == and ! =, the unary & operator, and the relational operators <, <=, >, >=.
My understanding of the rule is that confusion should be avoided when using the underlying type arithmetically.
My use-case is overloading operator<< for convenient logging and printing of an unscoped enum:


Code:
inline std::ostream& operator<<(std::ostream& os, MyEnum const& enum_value)
{
    switch (enum_value)
    {
        case MyEnum_Unknown:
        {
            return os << "Unknown";
        }
        case MyEnum_Val1:
        {
            return os << "Descriptive message... (MyEnum_Val1)";
        }//...
     }
}

Usage, where the warning is shown:
Code:
LOG_WARNING << "Could not perform action with " << enum_value;



So as long as the enum is not used in arithmetic context ie. bitwise operations (the enum is the left-hand operand) but with the streeam insertion operator I can not follow the rationale of the rule. Is this an oversight in the rule or is there a more specific reason behind this?]]> <![CDATA[A3-9-1 exception for using "unsigned char" for storage?]]> https://forum.misra.org.uk/showthread.php?tid=1662 Mon, 30 Oct 2023 12:52:05 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1662
However, how can we create storage in that case, since we don't have std::byte until C++17? We could use `std::uint8_t`, but that's not the type that is used in the Standard, and could potentially not be identical to "unsigned char" depending on platform.

Example use case:

Code:
alignas(T) unsigned char data[sizeof(T)];
T* p = new (data) T();
]]>
However, how can we create storage in that case, since we don't have std::byte until C++17? We could use `std::uint8_t`, but that's not the type that is used in the Standard, and could potentially not be identical to "unsigned char" depending on platform.

Example use case:

Code:
alignas(T) unsigned char data[sizeof(T)];
T* p = new (data) T();
]]> <![CDATA[A6-4-1 What is the definition of a "case-clause"?]]> https://forum.misra.org.uk/showthread.php?tid=1659 Wed, 11 Oct 2023 07:17:58 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1659
Rule A6-4-1 says:

Rule A6-4-1 (required, implementation, automated)
A switch statement shall have at least two case-clauses, distinct from
the default label.


What is the definition of a "case-clause"? Is it a "case-clause label", or a "case-clause block of code"?

Our static analyzer is warning about this code:


Code:
void foo(int i)
{
  switch(i)
  {
    case 3:
    case 7:
    case 12:
    case 25:
      doSomething();
      break;

    default:
      doSomethingElse();
      break;
  }
}


It warns because there is only one case "block of code" (doSomething), and it expects that there are at least 2 (distinct from default case). It then wants us to rewrite the code in a much less readable way, like:

Code:
if (i == 3 || i == 7 || i == 12 || i == 25)
{  
  doSomething();
}
else
{
  doSomethingElse()
}


Is our static analyzer correct in warning A6-4-1 in the above code?

Please note: A6-4-1 inherits from HIC++ HIC++ v4.0 [9]: 6.1.4, which is more explicit than AUTOSAR, claiming that "at least two case labels" are needed. There's a big difference between "label" and "block".

Furthermore, consider the documentation from Perforce about HIC++ 6.1.4:

https://www.perforce.com/resources/qac/h...statements

There, they claim that the following code is compliant (while not being compliant in AUTOSAR):


Code:
// @@+ Compliant: 2 case labels distinct from the default label +@@
switch (i)
{
  case 0:
  case 1:
    doSomething ();
    break;
  default:
    doSomethingElse ();
    break;
}

Why should AUTOSAR change the meaning of the HIC++ rule?

Thanks!]]>
Rule A6-4-1 says:

Rule A6-4-1 (required, implementation, automated)
A switch statement shall have at least two case-clauses, distinct from
the default label.


What is the definition of a "case-clause"? Is it a "case-clause label", or a "case-clause block of code"?

Our static analyzer is warning about this code:


Code:
void foo(int i)
{
  switch(i)
  {
    case 3:
    case 7:
    case 12:
    case 25:
      doSomething();
      break;

    default:
      doSomethingElse();
      break;
  }
}


It warns because there is only one case "block of code" (doSomething), and it expects that there are at least 2 (distinct from default case). It then wants us to rewrite the code in a much less readable way, like:

Code:
if (i == 3 || i == 7 || i == 12 || i == 25)
{  
  doSomething();
}
else
{
  doSomethingElse()
}


Is our static analyzer correct in warning A6-4-1 in the above code?

Please note: A6-4-1 inherits from HIC++ HIC++ v4.0 [9]: 6.1.4, which is more explicit than AUTOSAR, claiming that "at least two case labels" are needed. There's a big difference between "label" and "block".

Furthermore, consider the documentation from Perforce about HIC++ 6.1.4:

https://www.perforce.com/resources/qac/h...statements

There, they claim that the following code is compliant (while not being compliant in AUTOSAR):


Code:
// @@+ Compliant: 2 case labels distinct from the default label +@@
switch (i)
{
  case 0:
  case 1:
    doSomething ();
    break;
  default:
    doSomethingElse ();
    break;
}

Why should AUTOSAR change the meaning of the HIC++ rule?

Thanks!]]> <![CDATA[A7-1-2: Is it really intented to mark also functions as constexpr?]]> https://forum.misra.org.uk/showthread.php?tid=1657 Mon, 28 Aug 2023 09:37:52 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1657
A7-1-2 says:
The constexpr specifier shall be used for values that can be determined at compile time.

So it only talks about "values", not "functions". However, in the example, it says the following code is not compliant, because the function Pow1 "can be" constexpr but is not marked as such:

Code:
std::int32_t Pow1(std::int32_t number)
{
    return (number * number);
}
void Fn()
{
    const std::int32_t threeSquare = Pow1(3); // Non-compliant, possible run-time evaluation
}

On the other hand, examples are not normative - the title of the rule is.

Therefore I ask: is rule A7-1-2 intended to mark every single function as constexpr if it _can_ be constexpr?

In my opinion, this has negative consequences. Constexpr-ness of a function should be a careful design decision, not something added blindly to comply with a static analysis tool. It limits the way an author can choose to implement a given function. Maybe today the function _can_ be constexpr, but tomorrow as an author I want to refactor the implementation to e.g. use more modern libraries from STL, which don't have constexpr support in C++14 (for example, a silly std::array::operator[] is not supported in constexpr functions). Changing the implementation would require removing constexpr and updating also all the clients (which could dramatically cascade into second-order functions and so on). Or the alternative would be to be locked into constexpr and have to resort to older-style code to implement it (e.g. use a C array instead of std::array), making the function ultimately less safe and violating other Autosar rules.

Thanks!]]>
A7-1-2 says:
The constexpr specifier shall be used for values that can be determined at compile time.

So it only talks about "values", not "functions". However, in the example, it says the following code is not compliant, because the function Pow1 "can be" constexpr but is not marked as such:

Code:
std::int32_t Pow1(std::int32_t number)
{
    return (number * number);
}
void Fn()
{
    const std::int32_t threeSquare = Pow1(3); // Non-compliant, possible run-time evaluation
}

On the other hand, examples are not normative - the title of the rule is.

Therefore I ask: is rule A7-1-2 intended to mark every single function as constexpr if it _can_ be constexpr?

In my opinion, this has negative consequences. Constexpr-ness of a function should be a careful design decision, not something added blindly to comply with a static analysis tool. It limits the way an author can choose to implement a given function. Maybe today the function _can_ be constexpr, but tomorrow as an author I want to refactor the implementation to e.g. use more modern libraries from STL, which don't have constexpr support in C++14 (for example, a silly std::array::operator[] is not supported in constexpr functions). Changing the implementation would require removing constexpr and updating also all the clients (which could dramatically cascade into second-order functions and so on). Or the alternative would be to be locked into constexpr and have to resort to older-style code to implement it (e.g. use a C array instead of std::array), making the function ultimately less safe and violating other Autosar rules.

Thanks!]]>