Rule 9-3-2

[dg1980]

Dear MISRA team,

i think in the example below, the non-const get_p is a violation of this rule, while the static analysis tool says otherwise.
The compliant example in the document refers to shared data, which is not the case here.
I think it was misinterpreted as "returning a member of type T* is always compliant".
If so, maybe in the next version of the standard this rule needs a better formulation in terms of exceptions.

Code:

FlexeLint for C/C++ (Unix) Vers. 9.00L, Copyright Gimpel Software 1985-2014
--- Module: diy.cpp (C++)
     1  //lint -indirect(au-misra-cpp-alt.lnt)
     2  namespace
     3  {
     4    typedef unsigned char ui8;
     5    class cFoo
     6    {
     7    public:
     8      cFoo(void) : arr(), p(&arr[0]){}
     9      ui8* get_p(void){return p;}
    10      const ui8* get_p(void) const{return p;}
    11    private:
    12      ui8 arr[4];
    13      ui8* p;
    14    };
    15  }
    16  
    17  

--- Wrap-up for Module: diy.cpp

[misra cpp]

The non-const get_p is your example is compliant with 9-3-2, even if it is circumventing the aim of the rule.

The rule was drafted to prevent external functions directly modifying the contents of classes. In this case get_p is returning the value of p, not a handle that allows p to be modified. The fact that this allows arr to be modified is beyond the scope of the rule