MISRA Discussion Forums
Portal

Welcome, Guest
You have to register before you can post on our site.

Username
  

Password
  

  Clarification for rule 9-3-3
Posted by: dg1980 - 22-03-2017, 08:59 AM - Forum: 6.9 Classes (C++) - Replies (3)

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;
}
Print this item

  2-10-1 No "overlapping visibility" restriction?
Posted by: grunwald - 16-03-2017, 02:14 PM - Forum: 6.2 Lexical conventions (C++) - Replies (1)

C 2012 Directive 4.5: "Identifiers in the same name space with overlapping visibility should be typographically unambiguous"
C++ Rule 2-10-1: "Different identifiers shall be typographically unambiguous."

Does this mean the C++ rule applies even to identifiers in different scopes?

Code:
void f1() { int i; }
void f2() { int I; } // 2-10-1 violation due to only differing in case?

Also, does the C++ rule forbid naming a variables after their class name?

Code:
class MyClass { };
MyClass myClass;  // 2-10-1 violation?
Print this item

  C++0x
Posted by: aviargus - 15-03-2017, 03:06 PM - Forum: C++ General - Replies (1)

Hello,
I wanted to know if misra-c++ is going to support c++0x (or at least some of the features)?

Thanks,

Print this item

  "null pointer constant"?
Posted by: swestin - 08-03-2017, 11:06 PM - Forum: 8.11 Pointer type conversions - Replies (2)

The MISRA C:2012 guidelines (p. 93) define a "null pointer constant" as

the value 0, optionally cast to void *

Does this allow floating-point zero as a null pointer constant, e. g.

int32_t * pint = (void*)0.0f;

That seems crazy to me, but Rule 11.4 specifically allows a "null pointer constant that has integer type", whereas other mentions (Rules 11.1 and 11.2) omit "integer".

Was the intent to specify an integer zero?

Print this item

  Rule 6-4-5 Is return as last statement of a switch-clause also compliant to this rule?
Posted by: ProgCPlusPlus - 07-03-2017, 08:53 AM - Forum: 6.6 Statements (C++) - Replies (5)

Rule 6-4-5 requires an unconditional throw or break statement to terminate every non‑empty switch-clause.

But what about a return statement like in the example below.

Code:
switch ( x )
{
case 0:
   return;   // Compliant or non-compliant?
case 1:      // Compliant - empty drop through
   case 2:   // allows a group
   break;    // Compliant
case 3:
   throw;    // Compliant
case 4:
   a = b;
             // Non-compliant - non empty drop through
default:
   ;         // Non-compliant – default must also have "break"
}
The return statement for case 0: avoids an unintentional fall-through to next switch-clause.

For that reason an unconditional return at end of a switch-clause should make the switch-clause also compliant to this rule.

Is return as last statement of a switch-clause also compliant to this rule?

Print this item

  Rule 8-5-1 Must a non-static class member variable also explicitly initialized in constructor?
Posted by: ProgCPlusPlus - 07-03-2017, 08:22 AM - Forum: 6.8 Declarators (C++) - Replies (3)

The main statement of rule 8-5-1 is:

MISRA C++:2008 Wrote:Each class constructor shall initialize all non-static members of its class.
The example shows a compliant and a non compliant constructor of a class having only member variables of basic numerical type int32_t. It is clear that a member variable of a basic type must be initialized before first read access to avoid an undefined behavior.

But what about non-static members of a class being of type class.

Must a constructor of the class member variable explicitly called in the constructor to be compliant to this rule?

Example:

Code:
class A
{
   public:
      A ( ) : m_a( false )
      {
      }
      bool GetmA ( void )
      {
         return ( m_a );
      }
   private:
      bool m_a;
};


class B
{
   public:
      B ( ) : m_a( false )  // Compliant or non-compliant because of
      {                     // not explicitly calling constructor of m_b?
      }
      B ( const bool a ) : m_a( a ), m_b()  // Definitely compliant
      {
      }
      bool GetmA ( void )
      {
         return ( m_a );
      }
      bool GetmB (void )
      {
          return m_b.GetmA();
      }
   private:
      bool m_a;
      A    m_b;
};

int main ( void )
{
   B b;
   if ( b.GetmB() )
   {
   }
}
The default constructor of class A for member variable m_b is in both constructors of class B called, but in default constructor of class B only implicit according to C++ standard.

Is the default constructor of class B not explicitly calling default constructor of class A for member variable m_b compliant to rule 8-5-1?

Print this item

  Rule 8.5: Declarations vs Redeclarations in MISRA C versus MISRA C++
Posted by: RichardC - 02-03-2017, 12:45 PM - Forum: 8.8 Declarations and defnitions - Replies (3)

MISAR C++ 2008 provides a Glossary entry for 'declaration' with:

Quote: For the purposes of this standard, in headline rule text a
declaration is the first introduction of a name into a translation
unit. All subsequent “declarations” (as per ISO/IEC 14882:2003 [1]
§3.2(1)) are re-declarations.

This appears to differ from the MISRA C 2012 interpretation. Rule 8.5
includes the text:

Quote:... shall be declared once in one and only one file.

According to the MISRA C++ glossary entry, the use of "once" in the headline
text is redundant, as any additional declarations are "re-declarations".

Is the MISRA C meaning intended to be different to that of MISRA C++ 2008?

If so, could you provide an example where it is dangerous to use re-declarations?

Print this item

  Misra rule 20.3
Posted by: dvnarendra - 01-03-2017, 11:31 AM - Forum: 6.20 Standard Libraries - Replies (2)

Code:
#define MAX_BUF_LEN 20
#define MAX_ID_LEN    40

typedef struct
{
uint8_t  sno[MAX_BUF_LEN];
uint8_t  ID[MAX_ID_LEN ];'
} xdata_t;

typedef {
uint8_t   time;
uint32_t vol;
uint8_t ID[MAX_ID_LEN ];
}xpf_t

xdata_t  testdata;
xpf_t      pfdata
....
memcpy(pfdata.ID, testdata.ID, MAX_ID_LEN );  // Misra not compliant
......

I am using parasoft tool for checking misra compliance. for the above memcpy line I am getting the following misra non compliance

Values is "ID" passed to library function "memcpy" without being checked

I am using statically declared array. Why is it throwing this misra compliance? Can any one point how to make thsi line compliant

TIA
Narendra

Print this item

  Rule 13.6 - VLA, 'volatile' and Rule Exception
Posted by: RichardC - 28-02-2017, 12:54 PM - Forum: 8.13 Side effects - Replies (1)

A qualifier in the declaration of an array applies to the element type, C11 6.7.3/9:

Quote:If the specification of an array type includes any type qualifiers, the element type is so-
qualified, not the array type.

Code:
uint32_t f1 (int32_t x) {

      volatile int32_t a1[x];
               int32_t a2[x];

      return sizeof (a1) + sizeof (a2);
    }

The Exception to this rule includes:
Quote:... is an lvalue with a volatile qualified type that is not a variable-length array...

Given that the qualifier applies to the element type and not the array type, "not a variable-length array" is always true for an lvalue with volatile type. Is it the intention for 'sizeof(a1)' to be non compliant and for 'sizeof(a2)' to be compliant?

The Exception could be seen to add to the set of non-compliant cases even though nothing is written explicitly in the Amplification or Rationale.

Regards,

Richard

Print this item

  Did '\000' and 000 comply with Rule 2-13-2
Posted by: longfem - 28-02-2017, 06:09 AM - Forum: 6.2 Lexical conventions (C++) - Replies (1)

Dears,
Rule 2-10-3 said that Octal constants (other than zero) and octal escape sequences (other than “\0”) shall not be used.

From the description we know that '\0' and 0 comply with the rule.
How about '\00', '\000' , 00 and 000 ?

Thanks,
Longfem

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,207
» Latest member: MLBstubs
» Forum threads: 1,017
» Forum posts: 2,796

Full Statistics

Online Users
There are currently 154 online users.
» 0 Member(s) | 151 Guest(s)
Bing, Google, UptimeRobot

Latest Threads
Rule 7.0.5, example non-c...
Forum: 4.7 Standard conversions
Last Post: cgpzs
17-04-2025, 12:10 PM
» Replies: 0
» Views: 165
A3-3-2 Contradictory exam...
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
31-03-2025, 09:30 AM
» Replies: 2
» Views: 293
16.6.1 clarification
Forum: 4.16 Overloading
Last Post: cgpzs
31-03-2025, 09:29 AM
» Replies: 2
» Views: 277
Rule 9.3.1 - iteration st...
Forum: 4.9 Statements
Last Post: misra cpp
28-03-2025, 01:17 PM
» Replies: 1
» Views: 185
Rule 8.2.8 - why aren't a...
Forum: 4.8 Expressions
Last Post: misra cpp
28-03-2025, 01:05 PM
» Replies: 1
» Views: 205
Typo in Appendix C of MIS...
Forum: 8.10 The essential type model
Last Post: Yordan Naydenov
17-03-2025, 02:58 PM
» Replies: 0
» Views: 162
Adopted modal expressions...
Forum: General Questions
Last Post: Yordan Naydenov
17-03-2025, 09:01 AM
» Replies: 0
» Views: 254
Roadmap to c23 support
Forum: General Questions
Last Post: ACHart
28-02-2025, 03:23 PM
» Replies: 0
» Views: 211
Rule 6.2.1 weak linkage
Forum: 4.6 Basic concepts
Last Post: misra cpp
28-02-2025, 01:04 PM
» Replies: 1
» Views: 264
A8-4-5: Should have an ex...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
21-02-2025, 12:58 PM
» Replies: 3
» Views: 688