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

Username
  

Password
  





  Chapter 6.6.5 Iteration statements
Posted by: sklinger - 06-07-2018, 11:03 AM - Forum: 6.6 Statements (C++) - Replies (2)

Hello,

Regarding the rules 6-5-1, 6-5-2, 6-5-3, 6-5-4, 6-5-5, 6-5-6:
Do these rules only apply to for-loops or do they also apply to while-loops?

best regards,
Stefan

Print this item

  Rule M16.10
Posted by: phdenis - 04-07-2018, 10:47 PM - Forum: 6.10 Arithmetic Type Conversions - Replies (2)

Hello all,

I'm using the Misra 2004:C rules for the 1st time (e.g. I'm a newbie) and I got several errors linked to the rule M16.10 when I'm using the strncpy function like that:

Code:
strncpy(MyStr1,MyConstStr, sizeof(MyConstStr);

I've fixed this error by adding a pointer to the code which is not used.

Code:
char *MyPtr;
MyPtr = strncpy(MyStr1,MyConstStr, sizeof(MyConstStr);

So my question is:
For the functions like strncpy, memset and others functions of the same style, do we need to fix the misra error or do we have to justify it plainly?

By advance, thanks for your help.

Print this item

  Clarification for 7-4-1
Posted by: rrosier - 02-07-2018, 02:36 PM - Forum: 6.7 Declarations (C++) - Replies (1)

Rule 7-4-1 states that all usage of assembler shall be documented.

There are two ways that I could interpret this rule - and I was wondering which of these two was meant:

  1. That a cross-reference document is kept stating where assembly language is used.
  2. That all assembly language is documented with pseudo-code (or similar) such that it could be re-implemented in assembly language for a different processor (or even C/C++).

Is there any clarification about this available?

Print this item

  MISRA C:2012 Addendum 2 - clarifications
Posted by: Andrew Banks - 21-06-2018, 12:48 PM - Forum: General Questions - No Replies

Received via email:

Quote:I have a question about a couple of the "C Secure" rules that are marked as weak coverage in addendum 2 - and thought that perhaps the coverage could be upgraded if some of the rules from Amendment 1 were considered. We were wondering if the group could take a look at these and give us feedback. Thanks for your help.

C Secure Rule | Current Coverage MISRA C 2012 | Potential rules from Amendment 1
as stated in Addendum 2 to increase coverage
5.20 Weak Rule 21.15, Rule 21.17, Rule 21.18
5.26 Weak Dir 4.14
5.30 Weak Dir 4.14

Print this item

  MISRA C:2012 Addendum 2 - Rule 5.09 clarifications
Posted by: Andrew Banks - 21-06-2018, 12:37 PM - Forum: General Questions - Replies (1)

Received via email:

Quote:We have a question about the MISRA C:2012 - Addendum 2 document (version shown below).

Addendum 2 states the following regarding coverage of Rule 5.09 from "C Secure." We wanted to confirm with you that this is a type-o and that the referenced rule is intended to be 21.16, not 21.6. Thanks.

Print this item

  Rule 6-2-1 Assignment operators shall not be used in subexpressions
Posted by: nishiyama - 30-05-2018, 12:44 PM - Forum: 6.6 Statements (C++) - Replies (2)

Hello.

Why are the following MISRA Example compliant?
Is not a sub-expression?

Code:
if ( int16_t i = foo ( ) ) // Compliant
{
}

It looks like the following, but the following are non-compliant.
What are the differences?
Code:
if ( x = y ) // Non-compliant
{
 foo ( );
}

Print this item

  5.1 in practice
Posted by: danielmarjamaki - 23-05-2018, 09:37 AM - Forum: 8.5 Identifers - Replies (1)

I am not technically against 5.1. I just wonder how useful it is in practice.

Do you actually know a modern compiler that does not work well?

If you create a "too long" identifier will the modern compiler misbehave and create wrong code, or will they abort and complain to the user that an identifier is too long?

I created 2 external variables with 32000 characters and compiled with gcc and it seems to work fine.

Print this item

  semantic type checks
Posted by: danielmarjamaki - 22-05-2018, 01:46 PM - Forum: 8.10 The essential type model - Replies (1)

It is written in the misra document that the operands for > must be unsigned. In my humble opinion, you are missing something. Semantic type checks are not particularly safe, I claim they are dangerous.

Sanitizers, static analyzers and compilers are checking that the operands are not negative. By following this MISRA advice, these checks are "disabled".

Simple example code:

Code:
int32_t foo(void)
{
    int32_t x = -1;
    return x >> 3;
}

This is UB so the static analyzers/compilers/sanitizers will write a warning. For instance 1 tool writes:
Shifting a negative value is technically undefined behaviour

If MISRA is enforced then the operand must be casted to unsigned somewhere, the developer might change it to:
Code:
int32_t foo(void)
{
    int32_t x = -1;
    return (uint32_t)x >> 3;
}

Now the tools don't complain. The bug is hidden.

To help prevent some such damage, I have thought about a rule that makes such casts illegal, when there is loss of precision or loss of sign in explicit casts. But that is used by intention sometimes, as far as I know, so it might be noisy.

Print this item

  10.1 the calculation "50 << 3U" looks safe to me
Posted by: danielmarjamaki - 22-05-2018, 01:38 PM - Forum: 8.10 The essential type model - Replies (6)

In the description for 10.1 is is said that the calculation "50

Print this item

  Rule 17.5 and arrays of size 1
Posted by: gdavis - 15-05-2018, 10:09 PM - Forum: 8.17 Functions - Replies (1)

Hello,

Please consider the following case:

Code:
#include
extern void f(int32_t x[1]);
int32_t glob;
extern void test(void);
void test(void)
{
    f(&glob); /* Allowed under MISRA C 2012 R17.5? */
}

Could you confirm if the intent that this should be a violation of the rule since we are passing a non-array as an argument where an array is expected? I ask only because there is related wording in the C90/99 standard under additive operators that states:

Quote:For the purposes of these operators, a pointer to a nonarray object behaves the same as a
pointer to the first element of an array of length one with the type of the object as its element
type.

Thank you for your help.

Best Regards,

-Greg

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 428 online users.
» 0 Member(s) | 426 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: 19
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
21-11-2024, 01:12 PM
» Replies: 0
» Views: 30
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 355
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 315
model information blocks ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:27 PM
» Replies: 1
» Views: 4,436
MISRA AL SLSF - Rule 043I
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:11 PM
» Replies: 1
» Views: 8,853
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,479
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,681
Signal naming convention ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 07:57 AM
» Replies: 1
» Views: 7,234
Rule 7.0.2: operator cons...
Forum: 4.7 Standard conversions
Last Post: karos
14-10-2024, 08:52 PM
» Replies: 2
» Views: 421