Welcome to the MISRA discussion forum

Hi,

Rule 7.0.4 provides this example as compliant, and does not violate other rules  (like other examples)

Is Rule 6.7.1 intended to apply to local variables with thread storage duration?  For example:

Hi,

Rule 6.9.2 says it applies to "integral types constructed using the keywords char, ...". 
But it also says "it does not apply to the use of plain char".

This is confusing - is "char" allowed or not? Can you provide an example that shows where "char" is allowed and where it's not? I cannot find any in the rule explanation.

Thanks!

Hello,

Rule 7.0.1 allows for an explicit cast from bool to T when T has a converting constructor with a parameter of type bool. The example for the rule shows:

struct A
{
  explicit A ( bool );
};

A anA { true };       // Compliant - constructor

Yet, C++ requires a converting constructor to be non-explicit.

I'm not sure what the intent is, but perhaps the rule should allow for an explicit cast from B to T when T has an explicit constructor that takes a single parameter, a parameter of (possibly const-qualified) type bool.

Please advise. Thank you.

Rule 9.4.2 requires that all switch blocks have a "default" case, for defensive programming.

This is however not required when using C-style enums, i.e. unscoped and without underlying type. Presumably because it's Undefined Behavior to cast an int out-of-range to a C-style enum, whereas it's well-defined behavior for "C++ enums". Since UB is assumed to not happen, one can assume that a C-style enum has a valid value.

However, there's a subtlety. The "range" of a C-style enum is not just the list of valid enumerators, but the smallest bitset that contains all enumerators.

So for example:

Hi,

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!

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.