MISRA Discussion Forums
Portal

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

Username
  

Password
  

  Clarification for 7-4-3
Posted by: mikearmagedon - 28-03-2017, 06:52 PM - Forum: 6.7 Declarations (C++) - Replies (1)

Rule 7-4-3 states that "... assembly instructions shall be encapsulated and isolated in either assembler functions or C++ functions.".

Does assembler functions refers to assembly directives (.func and .endfunc) used in a .S file or it refers to C++ functions that encapsulate the assembly instructions?

Is the example compliant?
asm.S

Code:
.global foo
.func foo
foo:
...
.endfunc
main.cpp
Code:
extern "C" {
  void foo();
}

int main(void) {
  ...
  foo();
  ...
}
Print this item

  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

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,171
» Latest member: stephanmuench
» Forum threads: 998
» Forum posts: 2,752

Full Statistics

Online Users
There are currently 403 online users.
» 0 Member(s) | 400 Guest(s)
Applebot, Bing, Google

Latest Threads
Rule 6.2.1: non-inline co...
Forum: 4.6 Basic concepts
Last Post: cgpzs
Yesterday, 10:11 AM
» Replies: 0
» Views: 21
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
21-11-2024, 01:12 PM
» Replies: 0
» Views: 32
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 359
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 318
model information blocks ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:27 PM
» Replies: 1
» Views: 4,439
MISRA AL SLSF - Rule 043I
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:11 PM
» Replies: 1
» Views: 8,857
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,496
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,688
Signal naming convention ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 07:57 AM
» Replies: 1
» Views: 7,240
Rule 7.0.2: operator cons...
Forum: 4.7 Standard conversions
Last Post: karos
14-10-2024, 08:52 PM
» Replies: 2
» Views: 425