Rule 9-3-2

Moderators: david ward, misra cpp

Posts: 107
Joined: Wed Apr 27, 2016 2:33 pm
Company: Elektrobit Automotive GmbH

Rule 9-3-2

Postby dg1980 » Fri Oct 21, 2016 1:07 pm

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: Select all

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  }

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

misra cpp
Posts: 136
Joined: Mon Jun 02, 2008 1:55 pm
Company: MISRA

Re: Rule 9-3-2

Postby misra cpp » Mon Jul 10, 2017 11:47 am

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
Posted by and on behalf of
the MISRA C++ Working Group

Return to “6.9 Classes (C++)”

Who is online

Users browsing this forum: No registered users and 0 guests