Rule 6.8.4 clarification of amplification

[kth]

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

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

1.  . . . is (or evaluates to something that is) this, *this or a subobject of *this?
   
2.  . . . refers/points to (or evaluates to something that refers/points to) this, *this or a subobject of *this?
   
3.  . . . contains this, *this or a subobject of *this in any shape or form?
   
4. 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<float,10> 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.

[misra cpp]

We're not sure what distinction you are making between 1 & 2 - but they are basically the behaviour we require: A is non-compliant, B & C are compliant.

Basically we want to prevent returning a pointer/reference to a subobject of the class, whose lifetime may be longer than that of the object.

We also want to avoid the need for pointer tracing, so we're not interested in the source of B::ptr or what is subsequently done with the value returned by B::Get

Thanks for highlighting a real issue. We've noted that the wording of this rule may need clarification in the next issue.