<![CDATA[MISRA Discussion Forums - 6.9 Classes (C++)]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 15:13:50 +0000 MyBB <![CDATA[Unions and BitFields]]> https://forum.misra.org.uk/showthread.php?tid=1627 Tue, 05 Jul 2022 15:26:01 +0000 charles.obry@dana.com]]> https://forum.misra.org.uk/showthread.php?tid=1627
Rule 9-5-1 :  Could you please explain what it means by "all relevant implementation-defined behavious is documented"
Rule 9-6-1 :   Could you please see if the following code example would be compliant.


For exemple would the following code be acceptable with a deviation justification:

   typedef unsigned int  ubitfield_t;

    union EventSource
      {
        EventSource() { Reset(); }
        void    Reset() { all[0] = 0; }

        uint32_t all[1];
        struct EventSourceBits
        {
            ubitfield_t unused                            : 28;

            ubitfield_t unknownId            : 1;
            ubitfield_t InvalidHeader         : 1;
            ubitfield_t wrongCRC              : 1;
            ubitfield_t incompatible          : 1;

        } bits;
      };



Regards,
Charles]]>
Rule 9-5-1 :  Could you please explain what it means by "all relevant implementation-defined behavious is documented"
Rule 9-6-1 :   Could you please see if the following code example would be compliant.


For exemple would the following code be acceptable with a deviation justification:

   typedef unsigned int  ubitfield_t;

    union EventSource
      {
        EventSource() { Reset(); }
        void    Reset() { all[0] = 0; }

        uint32_t all[1];
        struct EventSourceBits
        {
            ubitfield_t unused                            : 28;

            ubitfield_t unknownId            : 1;
            ubitfield_t InvalidHeader         : 1;
            ubitfield_t wrongCRC              : 1;
            ubitfield_t incompatible          : 1;

        } bits;
      };



Regards,
Charles]]> <![CDATA[M9-3-1 and std::span-like classes]]> https://forum.misra.org.uk/showthread.php?tid=1600 Fri, 18 Feb 2022 09:42:18 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1600
Our static analyzer is reporting a violation of M9-3-1 in the following backport of C++20's `std:Confusedpan`:

Code:
template <typename T>
class Span
{
public:
   Span(T* const ptr, std::size_t size) :
      data_{ptr},
      size_{size}
   {}

T* data() const { return data_; }  // M9-3-1 reported here

private:
   T* data_;
   std::size_t size_;
};

int main()
{
    std::array<int, 3> arr{1,2,3};
    Span<int> s{arr.data(), arr.size()};
}


The `Span` class is merely a non-owning wrapper around a memory buffer. Furthermore, the `data()` function is not returning a reference to any class member, it's returning a copy of a class member. 

Would you say M9-3-1 is violated in this example?

Thanks!]]>
Our static analyzer is reporting a violation of M9-3-1 in the following backport of C++20's `std:Confusedpan`:

Code:
template <typename T>
class Span
{
public:
   Span(T* const ptr, std::size_t size) :
      data_{ptr},
      size_{size}
   {}

T* data() const { return data_; }  // M9-3-1 reported here

private:
   T* data_;
   std::size_t size_;
};

int main()
{
    std::array<int, 3> arr{1,2,3};
    Span<int> s{arr.data(), arr.size()};
}


The `Span` class is merely a non-owning wrapper around a memory buffer. Furthermore, the `data()` function is not returning a reference to any class member, it's returning a copy of a class member. 

Would you say M9-3-1 is violated in this example?

Thanks!]]> <![CDATA[9-3-3 and interfaces enforced via templates instead of virtual functions]]> https://forum.misra.org.uk/showthread.php?tid=1594 Wed, 15 Dec 2021 09:34:40 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1594
We are having trouble following Rule M9-3-3 when implementing interfaces using templates, similarly to the idea of "named requirements". I have read a similar post about this rule here and it's stated that the rule will be revised to also take the "override set" of virtual functions into account, making sure a function should be made const only if the whole "override set" can be made const.

Sometimes it might not be feasible to implement interfaces via virtual functions, and templates can be used to achieve the same result instead:

Code:
template <typename FooT>
void foo(FooT& f)
{
   f.run();
}


This pattern is commonly used e.g. in static dependency injection. We can pass any type `FooT` as long as it fulfills the interface `FooT::run`. For some types, `run` could be made const, but not all of them, therefore we get warnings from our static analyzers in such functions.

Will you consider this use case in the next revision of the rule? How do you suggest we work with it?

Thanks!]]>
We are having trouble following Rule M9-3-3 when implementing interfaces using templates, similarly to the idea of "named requirements". I have read a similar post about this rule here and it's stated that the rule will be revised to also take the "override set" of virtual functions into account, making sure a function should be made const only if the whole "override set" can be made const.

Sometimes it might not be feasible to implement interfaces via virtual functions, and templates can be used to achieve the same result instead:

Code:
template <typename FooT>
void foo(FooT& f)
{
   f.run();
}


This pattern is commonly used e.g. in static dependency injection. We can pass any type `FooT` as long as it fulfills the interface `FooT::run`. For some types, `run` could be made const, but not all of them, therefore we get warnings from our static analyzers in such functions.

Will you consider this use case in the next revision of the rule? How do you suggest we work with it?

Thanks!]]> <![CDATA[Question about an example from rule 9-3-1]]> https://forum.misra.org.uk/showthread.php?tid=1334 Fri, 07 Apr 2017 05:50:27 +0000 cxlin]]> https://forum.misra.org.uk/showthread.php?tid=1334
I have a question about the following example from rule 9-3-1:
Code:
class C {
public:
  C ( int &b_ ) : b( b_ ) { }

  int *getB () const
  {
    return &b;  // Non-compliant
  }
private:
  int &b;
}
Here `getB` actually returns a pointer to the object that `b` referenced, not the member `b` itself. And that object doesn't seem to satisfy the definition of "class data" by 1) it's not non-staitc member data, and 2) it's not a resource acquired in the constructor or released in the destructor. So I'm not sure why this is a Non-compliant case. Could you help to clarify a bit? Thanks!]]>
I have a question about the following example from rule 9-3-1:
Code:
class C {
public:
  C ( int &b_ ) : b( b_ ) { }

  int *getB () const
  {
    return &b;  // Non-compliant
  }
private:
  int &b;
}
Here `getB` actually returns a pointer to the object that `b` referenced, not the member `b` itself. And that object doesn't seem to satisfy the definition of "class data" by 1) it's not non-staitc member data, and 2) it's not a resource acquired in the constructor or released in the destructor. So I'm not sure why this is a Non-compliant case. Could you help to clarify a bit? Thanks!]]> <![CDATA[Clarification for rule 9-3-3]]> https://forum.misra.org.uk/showthread.php?tid=1327 Wed, 22 Mar 2017 08:59:11 +0000 dg1980]]> https://forum.misra.org.uk/showthread.php?tid=1327
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;
}
]]>
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;
}
]]> <![CDATA[Rule 9-3-2]]> https://forum.misra.org.uk/showthread.php?tid=1289 Fri, 21 Oct 2016 12:07:45 +0000 dg1980]]> https://forum.misra.org.uk/showthread.php?tid=1289
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
]]>
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
]]>