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

Username
  

Password
  





  Use reserved identifier as input parameter of function
Posted by: lai56 - 25-04-2017, 06:25 AM - Forum: 8.21 Standard libraries - Replies (1)

Hello,

It is defined in the Rule 21.2 that reserved identifier from standard library should not be used.

I have following example for a function definition.
void func_a (uint8 time)

time is reserved identifier from time.h, but it is used as input paramter for the function syntax. does it violate the rule 21.2?

Thanks
Lai

Print this item

  Rule 18-0-5 scope
Posted by: dg1980 - 19-04-2017, 10:47 AM - Forum: 6.18 Language support library (C++) - Replies (3)

Does this rule apply to memcpy as well?
The heading of the rule uses the generic term functions while the body of the rule explicitly lists all string functions -> confusing!
So, since memcpy is declared in the heading would fit here, while the body does not.
Nevertheless, since memcpy_s etc. is not available in C99/C++03 i think a deviation with reason "code quality/portability" would be justified.
Do you agree?

Print this item

  Rul 2.5: Definition of a project and unused code
Posted by: sca2012 - 18-04-2017, 08:56 PM - Forum: 8.2 Unused code - Replies (1)

This questions would rather belong to a specific forum for discussions of glossary terms but I could not find the appropriate section. My original question deals with the definition of "Project". I'll use example of unused code, but this issue could also be discussed in a context of other rules.

Let's say, I build an executable that makes use of a library, whose headers, say, contain a certain macro definition. This macro is not used anywhere in the source code of the executable directly, but it is used somewhere inside the library.

Is this situation compliant with Rule 2.5?

What if this library is actually a third party library whose source code is not available? Should the library itself be MISRA-compliant for the using code to be compliant (and thus definition of a "project" should also contain libraries and not only an executables)?

Print this item

  Clarification for underlying type of an integer constant expression
Posted by: huangcheng_synopsys - 14-04-2017, 02:08 AM - Forum: 6.5 Expressions (C++) - Replies (3)

According to MISRA C++ 2008 section 6.5, the underlying type of an integer contant expression is calculated based on its evaluated value. Griven expressions as below:

1. unsgined long v1 = 1UL; //Underlying type of "1UL" is unsigned char.
2. if(1) {//...} //Underlying type if "1" is signed char.
3. if(2000-1999){//...} //Underlying type of expression "2000-1999" is signed char.

Are the undelying type of above expressions correct? Then for the above three cases, there should be implicit cases as following:
1. unsigned char => unsigned long
2. signed char => int
3. signed char => int

Correct?

Print this item

  Question about an example from rule 9-3-1
Posted by: cxlin - 07-04-2017, 05:50 AM - Forum: 6.9 Classes (C++) - Replies (6)

Hi MISRA,

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!

Print this item

  Rule 11.3 pointer to array of const element
Posted by: grunwald - 06-04-2017, 01:55 PM - Forum: 8.11 Pointer type conversions - Replies (1)

Code:
static void use_array(uint8_t const (* const arr)[4])
{
}

int main()
{
    uint8_t aAction[4] = {0, 0, 0, 0};
    use_array((uint8_t const(*)[4]) &aAction); // 11.3 violation?
}

As I read rule 11.3, the cast in the use_array call violates rule 11.3: the target type of the pointer is "4-element array of const uint8_t". Given that the "const" is not at top-level, adding it is not permitted by this rule.

However, that raises the question: how can I call use_array() from Misra-compliant code?

Note that the cast is required by ISO C (gcc says: pointers to arrays with different qualifiers are incompatible in ISO C [-Wpedantic]).
However, in C++, an implicit conversion exists for this case.

Print this item

  Tool certification process
Posted by: dg1980 - 06-04-2017, 12:31 PM - Forum: General Questions - No Replies

Dear MISRA team,

please reconsider the need for a tool certification process in the future to avoid battles like this one: https://www.ibm.com/developerworks/commu...RA_CPP.doc
Any company can offer a MISRA tool these days and it is completely nontransparent for customers how good the support of the standard really is.
Very often, you find large holes in coverage of the standard after you purchased the tool.

Print this item

  Rule 5-0-3 false positive warning
Posted by: mikearmagedon - 04-04-2017, 02:59 PM - Forum: 6.5 Expressions (C++) - Replies (1)

My static analyzer is throwing the following warning:

Quote:MCPP Rule 5-0-3: This complex expression is implicitly converted to a different essential type
for the following code:
Code:
void func(const uint32_t arg)
{
    //32U has underlying type uint8_t
    const uint32_t u32a = arg % 32U; //warning issued in this line
    const uint32_t u32b = static_cast(arg % 32U); //compliant
}
I think this warning may be a false positive because, despite the 32U having a uint8_t underlying type, the expression should take the underlying type of the larger type, in this case the uint32_t, thus making the need for the static_cast unnecessary.

Do you agree this is a false positive? Or am I looking at it all wrong?

Print this item

  Rule 15.7, 16.4, side-effects and statements.
Posted by: RichardC - 04-04-2017, 12:04 PM - Forum: 8.15 Control flow - No Replies

Rule 15.7 "if...else if terminated by else" refers to "Rule 16.5". However, there appears to be a stronger relationship with 16.4: "Every switch shall have a default label". Should 16.4 be linked to 15.7?

In my opinion, there is a slight inconsistency between the rule rationale for 15.7 and 16.4 and what might be read as being covered.

Starting with Rule 15.7, the amplification requires a side-effect or a comment. Would you agree that this interpretation results in the following examples being 'non-compliant'?

Code:
void f1 (int x, int y)
  {
    for (int i = 0; i < 10; ++i)
    {
      if (i % x )
      {
      }
      else if (i % y)
      {
      }
      else
      {
        break;
      }
      /* Non-Compliant? Not a side-effect and not a comment */
    }
  }

  void f2 (int x, int y)
  {
    if (x != 0)
    {
    }
    else if (y != 0)
    {
    }
    else
    {
      return;
    }
    /* Non-Compliant? Not a side-effect and not a comment.
     * Non-compliant to advisory 15.5 */
  }

  void f3 (int x, int y)
  {
    if (x != 0)
    {
    }
    else if (y != 0)
    {
    }
    else
    {
      ;
    }
    /* Non-Compliant? Not a side-effect and not a comment. */
  }

  void f4 (int x, int y)
  {
    if (x != 0)
    {
    }
    else if (y != 0)
    {
    }
    else
    {
      goto END;
    }
    /* Non-Compliant? Not a side-effect and not a comment. */

  END:
    ;
  }

  void f5 (int x, int y)
  {
    for (int i = 0; i < 10; ++i)
    {
      if (i % x)
      {
      }
      else if (i % y)
      {
      }
      else
      {
        if (i != x)
        {
          if (i != y)
          {
            if ((i*i) > (x*y))
            {
            }
          }
        }
      }
      /* Non-Compliant? No comment or side-effect */
    }
  }

And the following examples would be compliant:

Code:
void f6 (int x, int y)
  {
    if (x != 0)
    {
    }
    else if (y != 0)
    {
    }
    else
    {
      /* Compliant */
    }
  }

  void f7 (int x, int y)
  {
    if (x != 0)
    {
    }
    else if (y != 0)
    {
    }
    else
      /* Compliant, but Non-Compliant with 15.6 */ ;
  }

  void f8 (int x, int y)
  {
    for (int i = 0; i < 10; ++i)
    {
      if (i % x)
      {
      }
      else if (i % y)
      {
      }
      else
      {
        if (i != x)
        {
          if (i != y)
          {
            if ((i*i) > (x*y))
            {
              /* Compliant? Comment "appears" in else. */
            }
          }
        }
      }
    }
  }

For Rule 16.4, the amplification requires a 'statement'. What do you feel is that status of the following examples?

Code:
void f9 (int x)
  {
    switch (x)
    {
    case 0:
      x+=1;
      break;
    case 1:
      x+=2;
      break;
    case 3:
      x+=3;
      break;
    default:
      ;
      break;
    }
    /* Compliant? Is ';' a statement? */

  }

  void fA (int x)
  {
    switch (x)
    {
    case 0:
      x+=1;
      break;
    case 1:
      x+=2;
      break;
    case 3:
      x+=3;
      break;
    default:
      { }
      break;
    }
    /* Compliant? Depends on interpretation of 16.1 regarding { } is a compound statement */
  }

  void fB (int x)
  {
    switch (x)
    {
    case 0:
      x+=1;
      break;
    case 1:
      x+=2;
      break;
    case 3:
      x+=3;
      break;
    default:
      { { } }
      break;
    }
    /* Compliant? Similar to fA */
  }

  void fC (int x)
  {
    switch (x)
    {
    case 0:
      x+=1;
      break;
    case 1:
      x+=2;
      break;
    case 3:
      x+=3;
      break;
    default:
      /* Compliant */
      break;
    }
  }

My reading of the Rationale is that the goal is have a 'defensive' comment unless the else does something, ie. the comment acts as a form of "Annotation".


Alternatively, going just from the rationale, I would mark the above functions as Compliant/Non-Compliant as follows:
  • f1: Compliant
  • f2: Compliant, Non-Compliant with rule 15.5.
  • f3: Non-Compliant
  • f4: Compliant
  • f5: Compliant
  • f6: Compliant
  • f7: Compliant, Non-Compliant with Rule 15.6
  • f8: Compliant (not because of nested comment)
  • f9: Non-Compliant
  • fA: Non-Compliant
  • fB: Compliant

What is the view of the MISRA C group on this?

Print this item

  Use of constexpr
Posted by: mikearmagedon - 31-03-2017, 02:15 PM - Forum: 6.1 General (C++) - Replies (1)

I am working on an embedded system project and using constexpr on the following situations:
- on constructors so that objects can be statically initialized in compile time
- on functions that are used to initialize constant values
- on constant variables, as an alternative to constant macros (as it violates rule 16-2-2)

The main reasons for using constexpr are (a)to avoid dynamic initialization, making the system more secure, and (b)to make better use of the system's ROM memory.

The constexpr is a language extension so a deviation procedure is necessary to allow its usage.

I would like to know first, if there is any way of achieving the same without the need to write a deviation procedure?

If such is not possible, are the reasons above enough to justify a deviation procedure?

Kind regards,
Miguel Araújo

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 293 online users.
» 0 Member(s) | 291 Guest(s)
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