Welcome to the MISRA discussion forum

I seek justification for why declaring a member function as volatile is considered an inappropriate use of the volatile qualifier.

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

Hello,
My question is about the third example for MISRA C++ 2023 Rule 9.6.2: "A goto statement shall reference a label in a surrounding block".

void f3(int32_t i, int32_t x, int32_t y)
{
  switch( i )
  {                                   // statement A
    case 0:
      if ( x < y )
        goto L3;                      // Non-compliant
      break;
    case 1:
    L3:
      break;
  }
}

I am not sure why this is non-compliant. In terms of the amplification of the rule, "A goto statement shall be enclosed in a statement that directly encloses its reference label", statement A is the compound statement as shown above. I believe the goto statement is enclosed within statement A, and statement A directly-encloses the reference label (L3).

The MISRA C 2012 and MISRA C 2023 versions of the equivalent rule 15.3 provide a different amplification that directly addresses this: "A switch-clause that does not consist of a compound statement is treated as if it were a block"

Please let me know what you think. Thank you.

Hello, could someone explain the following deviation requirement: 

"This deviation permit shall only be applied if the compiler's implementation has been verified to be consistent with the code generator's configuration (implicit or explicit)."

It is mentiond in rule 10.3, 10.4 and 10.8.
How to prove that this can be fullfilled? Could you refer to autocode?

Thanks!

MISRA AC SLSF:2023 Amendment 1 and MISRA AC SLSF:2023 Amendment 2 (which contains modifications that bring the guidelines up to date for MATLAB releases R2023b and R2024a, respectively) are now available as free downloads from the "MISRA AC resources" section of this Bulletin Board.

This Amendment to MISRA AC SLSF:2023 contains modifications that bring the guidelines up to date for MATLAB release R2024a

Attached Files

  MISRA AC SLSF 2023 AMD2.pdf (Size: 447.66 KB / Downloads: 5)

Hello,

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.
  

• 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
  

Hello,

Is there an Exemplar suite for MISRA C++ (either 2023 or 2008?). Looking around, I could not find one, but I wanted to check to make sure I am not missing anything.

Thank you!

Best Regards,

-Greg

It seems rule 15.0.1 has conflicting requirements for pure virtual / abstract classes with no data members. e.g. if we create the following classes:

• a protected non-virtual destructor.
  
• Unmovable class that has a public virtual destructor.
  

We would like to get clarification on what "opposite operators" means.

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 >?

Given the response from:  Rule 6-2-3 and C++17 [[fallthrough]]; attribute (misra.org.uk)
Should Rule 6-4-3(A switch statement shall be a well-formed switch statement) and Rule 6-4-5(An unconditional throw or break statement shall terminate every non-empty switch-clause) also have an exception for the [[fallthrough]]; attribute when used in an empty switch case?