+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C++ (https://forum.misra.org.uk/forumdisplay.php?fid=18)
+--- Forum: MISRA C++:2008 rules (https://forum.misra.org.uk/forumdisplay.php?fid=19)
+---- Forum: 6.9 Classes (C++) (https://forum.misra.org.uk/forumdisplay.php?fid=138)
+---- Thread: Rule 9-3-2 (/showthread.php?tid=1289)
Rule 9-3-2 - dg1980 - 21-10-2016
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.cppRe: Rule 9-3-2 - misra cpp - 10-07-2017
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