MISRA Discussion Forums - 4.6 Basic concepts

Rule 6.5.2: Missing exception for static class members?

Tue, 02 Jun 2026 07:14:08 +0000

The wording of rule 6.5.2 seems to imply that any entity with internal linkage may not be declared static, even though the static keyword “also has other uses”.
With that interpretation, the rule would completely prohibit the use of static class members with internal linkage.

For example, given this code snippet:

Code:
static void F1() {} // 1

namespace {

static void F2() {} // 2

class Klass {

  public:

    static void F3() {} // 3

};

} // namespace

In cases 1 and 2, the static keyword is “inappropriate”. F1 should be declared inside the anonymous namespace instead and for F2 the static keyword could be simply dropped.
F3 has internal linkage but the static is not used for linkage but to make the function a class function. Still, the amplification of rule 6.5.2 says that internal linkage of an entity is only appropriate if it’s not declared static, which F3 clearly is.

Is that intentional? Should the wording be improved to make it clear that only static declarations which could affect linkage are considered?
Or (to simplify static analysis) could an exception be added for static class members?

Rule about extern "C" and missing exceptions

Mon, 04 May 2026 16:24:26 +0000

Currently, MISRA C++:2023 mentions "extern C" as part of the following rules:

title of Rule 6.0.3 (The only declarations in the global namespace should be main, namespace declarations and extern "C" declarations),
exception 2 of Rule 10.2.1,
amplification and rationale of Rule 18.4.1 and
as part of different examples (e.g., in Rule 19.0.3)

However, until now there is no rule provided that limits the keywords etc. can be "safely" used inside of an extern "C" block.

Wouldn't that be helpful?

Examples:

what happens when I define a namespace inside of an extern "C" block?
what happens when I define or declare (accidentally) a class in an extern "C" block?
what happens when I use a C++ reference in a function signature like "int foo(int& in_out)"?
Basics: the C compiler does not know extern "C". Consequently, it should be surrounded by ´#ifdef __cplusplus´ and ´#endif´.
...

What about exceptions for extern "C" in the rules

11.3.1 (Variables of array type should not be declared) as in an extern C block a std::array is not available.
10.2.2 (Unscoped enumerations should not be declared) - notice that for 10.2.1 an exception si defined

Code example (https://godbolt.org/z/EG7Y9dxdh):

Code:
// some header.h - shared between C and C++

#ifdef __cplusplus

#include 

#else

#include 

#endif

#ifdef __cplusplus

extern "C" {

#endif

  typedef int MyInt;  /* likely OK */

  void foo();  /* likely not OK */

  struct X { int a; };  /* is this OK? */  

  struct Y { int32_t b; };  /* or this? */  

  struct Z { char c[3]; };  /* or this? */  

  namespace dummy {  /* and this? */

    class C {  /* or this - note: maybe the #ifdes __cplusplus guard is missing ...  */

    public:

      int val{2};

    };

  }

#ifdef __cplusplus

}

#endif

// c++ code

int main() {

  dummy::C c1;

  return c1.val;

}

Rule 6.0.3 and extern "C"

Mon, 04 May 2026 15:12:09 +0000

Rule 6.0.3 has the title

Quote:The only declarations in the global namespace should be main, namespace declarations and extern "C" declarations

However, with the current MISRA C++:2023 version the amplification does not contain details about the extern "C" declarations and there are no examples that use an extern "C" block.

My question first question: is it OK to use typdefs in extern "C" blocks and also in the global namespace to be able to share these typdefs between C and C++ code?

Example:

Code:
#ifdef __cplusplus

#include 

#else

#include 

#endif

#ifdef __cplusplus

extern "C" {

#endif

typedef uint16_t AddressType_t;  /* Compliant? (to be able to share typdefs in C and C++ code this is OK) */ 

void foo();                      /* Compliant? ('foo' needs C linkage and it is OK to have a C function in the global namespace) */

#ifdef __cplusplus

}

#endif

Second question: As the rule explicitly mentions extern "C" declarations - what else is allowed or not allowed? (What about, e.g., struct definitions or function definitions?)

Rule 6.9.1 and (possibly) qualified identifiers / name lookup / namespaces

Fri, 24 Apr 2026 14:10:30 +0000

Hello,

We are wondering how Rule 6.9.1 shall be understood when namespaces and name lookups are involved.
Rule's rationale is about avoiding confusion. But, especially, the examples only address very basic (mis)uses, i.e., using obviously different type (alias) names in (re-)declarations. Very C-like...

It is unclear, when it comes to (namespace) qualification and (re-)introducing names into namespaces or scopes.
Under those conditions, it becomes fuzzy what is meant with "the same type alias": Is it just the spelling of the name (including qualification)? Is it the definition, i.e. resulting the underlying type? Or, is it the same qualified name (regardless how it was spelled in code - i.e., whether and how it was qualified)?
Maybe, it even is (or should be) out of scope of rule 6.9.1?

Example:

Code:
namespace n {

 struct S {};

 using Alias = S;

 Alias foo(); // (0)

 S bar();

}

auto n::foo() -> Alias; // (1)

n::Alias n::foo(); // (2) with leading return type I have to use the namespace.

using Alias = n::Alias;

auto n::foo() -> Alias; // (3)

Alias n::foo(); // (4)

namespace m {

 class Klass {

 public:

    using S = n::S;

    using Alias = n::S;

    friend Alias n::foo(); // (5)

    friend S n::bar(); // (6)

    explicit Klass(n::S const&);

};

using n::S;

auto Klass(S const&); // (7)

}

First observation: It doesn't seem to be always about type aliases, but about the question, wich type (name) will be eventually used. This might be out of scope of Rule 6.9.1, but it is still related to developer's expectation / possible confusion.

Note: to keep the examples simple, I'd judge "compliance" always only considering any difference to the initial declaration, e.g., (0).
(In practice, one violating declaration probably would cause the whole set of declarations being not compliant.)

(1): Is most definitely compliant, as both indeed use the very same type alias, in all respects.
(2): Compliant? It "names" the same alias, but it is "spelled" (i.e., it looks) differently. Might lead to confusion?
(3): Compliant? Maybe; which alias will be used? Should it matter in this case?
(4): Compliant? Same (unqualified) name ist used, but in the end it is a different alias, still resulting in the same type. Regarding the underlying type, one could argue, it is still the same alias.
(5): Compliant? Similar to (4); just to demonstrate a friend declaration.
(6): Compliant? Original declaration didn't even use a type alias - maybe, not even in scope? Still same "name".
(7): Compliant? IMO, actually not in scope, because type aliases are not used in any declaration of that entity.

Personally, I don't have a strong opinion on that. I just found declarations of those kinds in our codebase. Thus, I'm asking for clarification.
IMHO, using same names (qualified or unqualified) seems to match expectations it could be okay, as long as they do result in same types.
Mixing different qualifications within one scope (class or namespace) is quite confusing as well (such as (1) and (2), even though namespace qualification is required for (2))

Thank you very much,
Best regards.

Rule 6.7.1 and local declarations with external linkage

Tue, 27 Jan 2026 15:26:01 +0000

Is this rule intended to apply to variable declarations of external linkage? For example:

Code:
int main()

{

    extern int var;

    var = 4;

}

'var' is declared at block scope, refers to an object of static storage duration and is not const-qualified. Hence, it appears to be non-compliant with this rule.

However, my feeling is that it does not really fit the rationale of the rule as it does not add persistent state to the function (this declaration cannot be a definition, so some definition of var must exist outside of main). One could argue that var is effectively not local to the function containing the declaration.

Can you please clarify?

PS: I'm aware that such code does not comply with other rules as well (e.g. 6.7.2).

Distinction between rule 6.8.1 and 6.8.4

Thu, 15 Jan 2026 10:41:27 +0000

Hi,

rule 6.8.4 covers a decidable subset of rule 6.8.1.
The scope of rule 6.8.4 is limited by the phrase "explicitly designates".
I am not sure about the exact meaning of "explicitly designates" and I hope for a clarification.

Here is a list of cases I am not sure about.
I put my interpretation of "explicitly designates" as comments in the code.

Code:
struct A {

  int m_a;

  int m_b;

  const int &a() const { // non-compliant - m_a as subobject explicitly designated

    return m_a;

  }

  const int &b() const { // compliant as rule does not apply? Or is ++m_a an explicit designation of subobject m_a?

    return ++m_a;

  }

  const int &c() const { // compliant as rule does not apply? Or is this expression an explicit designation of m_a/m_b too?

    return cond ? m_a : m_b;

  }

  const int &d() const { // compliant as rule does not apply? calling a() somehow designates m_a, but not "explicitly", right?

    return a();

  }

  const int *e() const { // compliant as rule does not apply as shown by examples for rule 6.8.4

    const int *p = &m_a;

    return p;

  }

};

All functions clearly violate the undecidable rule 6.8.1, but which functions should violate 6.8.4 too?

Thanks in advance.

Rule 6.9.2: Are non-top level users of basic types permitted in an alias?

Thu, 09 Oct 2025 23:06:20 +0000

Hi,

The first exception for Rule 6.9.2 permits the use of a basic type to define a type alias. I guess the wording may be more broad than intended. For example,is the following permitted?

Code:
#include 

typedef std::list int_list;

Thank you!

Rule 6.8.4 clarification of amplification

Fri, 08 Aug 2025 08:06:08 +0000

The amplification of rule 6.8.4 leads with this sentence to clarify to which member functions this rule applies:

Quote:This rule applies to member functions with reference or pointer return type, where, in the definition of the function, at least one
return expression explicitly designates this, *this or a subobject of *this.

The usage of the word “designates” here is ambiguous.
Does it mean the expression . . .

. . . is (or evaluates to something that is) this, *this or a subobject of *this?
. . . refers/points to (or evaluates to something that refers/points to) this, *this or a subobject of *this?
. . . contains this, *this or a subobject of *this in any shape or form?
A combination of the above?

Depending on which interpretation is true, the following code examples are either
compliant or non-compliant:

Code:
class A {

std::int32_t data_;

public:

// returns a pointer to data member

std::int32_t const* Get() const { return &data_; }

};

class B { 

std::int32_t* ptr_;

public:

// returns data member which is a pointer to an

// object with lifecycle independent of "this" 

std::int32_t* Get() const { return ptr_; }

};

class C { 

std::int32_t idx_;

public:

// returns unrelated pointer based on data member

float const* Get(std::array const& data) const { return &data[idx_]; }

};

The intent of the rule seem to support meaning number 2, which would mean only A::Get is non-compliant.
If that is the case, we suggest to replace “designates” with a less ambiguous phrase, e.g. “references/points to” or to explain more clearly what is meant in the amplification.
In addition, clarifying examples for these cases would be helpful.

Rule 6.7.2 variable templates

Thu, 24 Jul 2025 18:55:00 +0000

Is the following considered to be compliant:

Code:
template 

T var = 42;

By itself it seems not to be in the spirit of the rule since there's no "const" in the declaration. But what if the only instantiation is something like:

Code:
int foo() { return var; }

Thank you.

Rule 6.2.1 weak linkage

Fri, 28 Feb 2025 09:33:42 +0000

Dear MISRA group,

I have a question regarding the interpretation of the one-definition-rule in the presence of weak linkage (i.e. __attribute__((weak))).
In particular, is it considered a violation of the odr rule/rule 6.2.1 if a function with "strong" linkage "overrides" a function with "weak" linkage (as typically found in (standard) libraries)?

A special case within this discussion are global allocation and deallocation functions. The C++ standard calls them explicitly "replaceable".
Implementation-wise in any standard library I know, this is expressed by the weak linkage attribute.
Since the standard allows these few functions to be replaced explicitly, I conclude this does not constitute a violation of the one-definition-rule.

But how about any other weak-linkage function?

Thanks in advance!

Rule 6.2.1: non-inline constexpr variables in headers?

Fri, 22 Nov 2024 10:11:39 +0000

Hi,

Consider the following example:

Code:
// foo.h

constexpr int kFoo = 123;

inline int foo(int x)

{ 

  return x * kFoo;

}

// tu1.cpp

#include "foo.h"

int tu1() { return foo(1); }

// tu2.cpp

#include "foo.h"

int tu2() { return foo(2); }

Does the function "foo" violate Rule 6.2.1 in this context, given that kFoo is not a C++17 inline variable?
Or would it violate 6.2.1 only if kFoo were ODR-used (for example, passed by reference)?

Thanks!

Rule 6.7.1 and thread storage duration

Tue, 10 Sep 2024 18:40:41 +0000

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

Code:
typedef int int32_t;

void foo() {

    static int32_t var1{0};        // Non-compliant

    thread_local int32_t var2{0};  // Compliant ???

    /* ... */

}

While the rule specifically references "static storage duration" it is not clear what the intended impact of this rule is with respect to "thread storage duration" variables. While local variables with thread storage duration do not suffer the same intrinsically thread-unsafe characteristics as those with static storage duration, the provided Rationale still applies. In particular, they decrease comprehensibility, introduce temporal coupling, and can result in (reentrant) data races.

Rule 6.9.2: Unclear interpretation about "char"

Tue, 03 Sep 2024 07:52:17 +0000

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!

Rule 6.9.2: Missing exception for user-defined literals?

Mon, 26 Feb 2024 19:59:43 +0000

MISRA C++ rule 6.9.2 (The names of the standard signed integer types and standard unsigned integer types should not be used) defines two exceptions (shortened):
1. for type aliases
2. postfix operator, return type of main and argc of main.

Currently, there is no exception for user-defined literals.

However, the C++ standard defines as part of [over.literal] §16.5.8.3:

Code:
3 The declaration of a literal operator shall have a parameter-declaration-clause equivalent to one of the

following:

const char*

unsigned long long int

long double

char

wchar_t

char16_t

char32_t

const char*, std::size_t

const wchar_t*, std::size_t

const char16_t*, std::size_t

const char32_t*, std::size_t

If a parameter has a default argument (11.3.6), the program is ill-formed.

Is a exception for user-defined literals missing?