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

Username
  

Password
  





  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

  Rule 5.6 A ty pedef name shall be a unique identifier
Posted by: xiaoxin - 09-05-2018, 07:36 AM - Forum: 8.5 Identifers - Replies (2)

My doubt about this rule is if they violate rules in different files, as follows.If they violate the rules in the same project.
a.c

Code:
void func ( void )
{
    {
        typedef unsigned char u8_t;
    }
}
b.c
Code:
void func ( void )
{
    typedef unsigned char u8_t;
    â€¦â€¦
    
}
Similarly, there are rules 5.3 : An identifi er declared in an inner scope shall not hide an identifier declared in an outer scope
c.c
Code:
int a =8;
d.c
Code:
void main(){
int a = 9;
}
In other words, whether cross-document considerations are considered。
Looking forward to your reply。

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,206
» Latest member: nileseo4605
» Forum threads: 1,017
» Forum posts: 2,796

Full Statistics

Online Users
There are currently 176 online users.
» 0 Member(s) | 173 Guest(s)
Applebot, Bing, 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: 161
A3-3-2 Contradictory exam...
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
31-03-2025, 09:30 AM
» Replies: 2
» Views: 288
16.6.1 clarification
Forum: 4.16 Overloading
Last Post: cgpzs
31-03-2025, 09:29 AM
» Replies: 2
» Views: 272
Rule 9.3.1 - iteration st...
Forum: 4.9 Statements
Last Post: misra cpp
28-03-2025, 01:17 PM
» Replies: 1
» Views: 181
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: 202
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: 160
Adopted modal expressions...
Forum: General Questions
Last Post: Yordan Naydenov
17-03-2025, 09:01 AM
» Replies: 0
» Views: 246
Roadmap to c23 support
Forum: General Questions
Last Post: ACHart
28-02-2025, 03:23 PM
» Replies: 0
» Views: 204
Rule 6.2.1 weak linkage
Forum: 4.6 Basic concepts
Last Post: misra cpp
28-02-2025, 01:04 PM
» Replies: 1
» Views: 260
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: 675