MISRA Discussion Forums

Full Version: Clarification for rule 9-3-3
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Dear MISRA team,

to me the rule text sounds like an if/else instruction for a static analysis tool vendor, e.g.:

Code:
if (static_possible[ast_cur_sym])
{
  print("[MISRA C++ 9-3-3] %s could be made static", ast_cur_sym);
}
else
{
  if (const_possible[ast_cur_sym])
  {
    print("[MISRA C++ 9-3-3] %s could be made const", ast_cur_sym);
  }
}

Can you confirm?
Thanks.

Background: in the sample code below i would expect to get "[MISRA C++ 9-3-3] nfoo::cfoo::get could be made static" while some static analyzers suggest const instead.

Code:
namespace nfoo
{
  typedef int si32;
  class cfoo
  {
  public:
    si32 get(void){return x;}
  private:
    static si32 x;
  };

  si32 cfoo::x = 0;
}
You are correct - if your tool says it should be const - contact your tool vendor
The scope for this rule shall be clarified in the next version in such a way that it is clear whether virtual member functions are included or excluded.
Our static analyzer has a different, non-MISRA related message for virtual members that could be const, because then all derived implementations would have to be const as well (which might not be possible/wanted).
Thanks.
We'd agree that the current position is ambiguous. This is to be considered for the next version - the likely outcome being that this applies to all functions, including virtual members. However, for virtual functions the requirement only applies if all virtual functions in an override set can be made const