MISRA Discussion Forums
Distinction between rule 6.8.1 and 6.8.4 - Printable Version

+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C++ (https://forum.misra.org.uk/forumdisplay.php?fid=18)
+--- Forum: MISRA C++:2023 guidelines (https://forum.misra.org.uk/forumdisplay.php?fid=188)
+---- Forum: 4.6 Basic concepts (https://forum.misra.org.uk/forumdisplay.php?fid=192)
+---- Thread: Distinction between rule 6.8.1 and 6.8.4 (/showthread.php?tid=1761)

Distinction between rule 6.8.1 and 6.8.4 - hahn - 15-01-2026

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.

RE: Distinction between rule 6.8.1 and 6.8.4 - misra cpp - 23-01-2026

Your examples don't necessarily violate 6.8.1, as this requires a >use< of the reference returned by these functions after the lifetime of the A object has ended - often Undecidable.

6.8.4 is the more precautionary, but Decidable, rule that attempts to stop you generating dangling references, that could lead to violations of 6.8.1. 

Our view is that your examples 'a', 'b' and 'c' are all non-compliant with 6.8.4 , as they all return a reference to a member that might be used after the object's lifetime.

Example 'd' is compliant, as its not obvious that a() returns a reference to a member variable. There's no expectation that an analyser will analyse the behaviour of a() to ensure that a() isn't going to return a reference to a member variable by some complex process.

Example 'e' is also compliant. We'd prefer that it wasn't, because you are getting a pointer to a member variable that may lead to a 6.8.1 violation, but for simplicity the rule doesn't address this case.

We are considering the following definition of "explicitly designates" to clarify the intent:
"explicitly designates" means that a simple evaluation of the return expression in isolation, can determine if a reference to the object or sub-object is being returned, i.e. without the need to evaluate function calls or track pointers etc.

RE: Distinction between rule 6.8.1 and 6.8.4 - misra cpp - 25-01-2026

In addition, we intend to clarify "explicitly designates" with the following example (or something similar):

int arr[10];
 
struct A {
  int m_a;
 
  const int &a() const { // compliant - the return expression references m_a, but does not designate it.
    return arr[m_a];
  }
};