<![CDATA[MISRA Discussion Forums - 4.10 Declarations]]>

<![CDATA[MISRA Discussion Forums - 4.10 Declarations]]> https://forum.misra.org.uk/ Thu, 12 Nov 2026 16:20:30 +0000 MyBB <![CDATA[Rule 10.1.1]]> https://forum.misra.org.uk/showthread.php?tid=1745 Mon, 04 Aug 2025 07:59:07 +0000 Merge]]> https://forum.misra.org.uk/showthread.php?tid=1745 Hi,

We are having a discussion with one of our tool vendors about how to interpret MISRA C++ 2023 rule 10.1.1, more concretely, the impact of the implicit 'this' parameter. I won't say which party supports which interpretation for the sake of neutrality.

Example code:
https://godbolt.org/z/hxz4bzvan

Interpretation A)
Fn() has an implicit, non-const 'this' parameter, so the rule is violated (Fn() should have been declared const).

Interpretation B)
Fn() does not have any parameters, so the rule is not violated.

We would appreciate an unbiased opinion to settle this discussion.

Best regards,
Daniel "Merge" Merget]]> Hi,

We are having a discussion with one of our tool vendors about how to interpret MISRA C++ 2023 rule 10.1.1, more concretely, the impact of the implicit 'this' parameter. I won't say which party supports which interpretation for the sake of neutrality.

Example code:
https://godbolt.org/z/hxz4bzvan

Interpretation A)
Fn() has an implicit, non-const 'this' parameter, so the rule is violated (Fn() should have been declared const).

Interpretation B)
Fn() does not have any parameters, so the rule is not violated.

We would appreciate an unbiased opinion to settle this discussion.

Best regards,
Daniel "Merge" Merget]]> <![CDATA[Rule 10.1.2: Justification for considering volatile member functions as inappropriate]]> https://forum.misra.org.uk/showthread.php?tid=1696 Wed, 14 Aug 2024 15:34:24 +0000 Nicolas Huch]]> https://forum.misra.org.uk/showthread.php?tid=1696
The other inappropriate use cases (local variables, function parameters, function return types, and structured bindings) are justifiable to me since they are not bound to specific memory addresses, which may be out of scope for the C++ virtual machine to reason about. Instead, they are typically automatic variables located on the stack or only exist in registers, which conflicts with the concept of volatile.

However, a class object might be located at a specific memory address where it could abstract a memory-mapped register. Such an object must be declared as volatile. To call non-static member functions on such an object, those functions must also be declared as volatile.

The justification for all of the inappropriate use cases mentions that the behavior is not well-defined or well-understood, but the standard clearly states the behavior in the case of non-static member functions:

Declaring a non-static member function as volatile will influence the type of the this pointer as well as the member function type (12.2.2 [4]). Section 12.2.2.1 [1] further clarifies that the type of the object referred to by the this pointer is qualified with the same cv-qualifiers as those used for the non-static member function.

Additionally, MISRA Rule 10.1.2 explicitly states in a note that "a pointer or reference to a volatile entity is permitted", which contradicts the notion that declaring a volatile member function is an inappropriate use of the volatile qualifier.

Are there further aspects I am missing or wrong assumptions in my reasoning?

Kind regards
Nicolas]]>
The other inappropriate use cases (local variables, function parameters, function return types, and structured bindings) are justifiable to me since they are not bound to specific memory addresses, which may be out of scope for the C++ virtual machine to reason about. Instead, they are typically automatic variables located on the stack or only exist in registers, which conflicts with the concept of volatile.

However, a class object might be located at a specific memory address where it could abstract a memory-mapped register. Such an object must be declared as volatile. To call non-static member functions on such an object, those functions must also be declared as volatile.

The justification for all of the inappropriate use cases mentions that the behavior is not well-defined or well-understood, but the standard clearly states the behavior in the case of non-static member functions:

Declaring a non-static member function as volatile will influence the type of the this pointer as well as the member function type (12.2.2 [4]). Section 12.2.2.1 [1] further clarifies that the type of the object referred to by the this pointer is qualified with the same cv-qualifiers as those used for the non-static member function.

Additionally, MISRA Rule 10.1.2 explicitly states in a note that "a pointer or reference to a volatile entity is permitted", which contradicts the notion that declaring a volatile member function is an inappropriate use of the volatile qualifier.

Are there further aspects I am missing or wrong assumptions in my reasoning?

Kind regards
Nicolas]]> <![CDATA[10.2.3 Amplification]]> https://forum.misra.org.uk/showthread.php?tid=1678 Tue, 26 Mar 2024 15:08:25 +0000 hahn]]> https://forum.misra.org.uk/showthread.php?tid=1678
I find the amplification of rule 10.2.3 confusing.

In general I wonder what the difference to a simple "no implicit conversion from unscoped enumeration type without underlying type to numeric type" (plus the exception for static_cast in bullet point 3) is?

In particular, as example, for the following code

Code:
enum E {E1, E2};

int f(int);

E operator+(E, E);

int main() {

  E e = E1;

  f(e); // Compliant? (1)

  e = e + e; // Non-compliant (2)

}

I wonder whether (1) should be compliant or not. At least it is not listed in the amplification, but seems like a problematic case anyway.
In turn, should (2) be non-compliant as operands to "arithmetic operator" are explicitly listed in the amplification, while I think this case is absolutely fine.

It would be great to get a clarification on what the rule intends.]]>
I find the amplification of rule 10.2.3 confusing.

In general I wonder what the difference to a simple "no implicit conversion from unscoped enumeration type without underlying type to numeric type" (plus the exception for static_cast in bullet point 3) is?

In particular, as example, for the following code

Code:
enum E {E1, E2};

int f(int);

E operator+(E, E);

int main() {

  E e = E1;

  f(e); // Compliant? (1)

  e = e + e; // Non-compliant (2)

}