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

Username
  

Password
  





  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

  Rule 7-5-3 and storing a reference for later use
Posted by: rrosier - 08-05-2018, 01:12 PM - Forum: 6.7 Declarations (C++) - Replies (4)

Hello,

I am curious if Rule 7-5-3 is only applicable when a reference to a parameter that is passed by const reference is returned from a function, but also if that reference is stored and then used later.

The rationale of the rule states that "It is implementation-defined behaviour whether the reference parameter is a temporary object or a reference to the parameter." and then goes on to say that a temporary object will be destroyed when the function returns and that using an object after its destruction will lead to undefined behaviour.

Considering the following code:

Code:
class TestConstRef
{
public:
  TestConstRef(const T& aT) : mT(aT) {}
  ~TestConstRef() {}

private:
  const T& mT;
};

If I understand the rule correctly, the parameter aT could be a temporary object which will be destroyed when the constructor exits and when the member reference mT is used later, the temporary object that it refers to may (depending on the implementation) no longer exist and that will lead to undefined behaviour.

Could I ask:
  • Is this understanding correct?
  • Is so, why is only returning the reference explicitly covered by the rules, and not storing the reference as in the code snippet above?

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,309
» Latest member: 1fuhd
» Forum threads: 1,066
» Forum posts: 2,933

Full Statistics

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

Latest Threads
13.2 Was TC2 correctly ap...
Forum: 8.13 Side effects
Last Post: misra-c
08-10-2026, 12:47 PM
» Replies: 1
» Views: 624
20.12 Does the stringific...
Forum: 8.20 Preprocessing directives
Last Post: misra-c
08-10-2026, 12:40 PM
» Replies: 1
» Views: 554
13.3 Should side effects ...
Forum: 8.13 Side effects
Last Post: misra-c
08-10-2026, 12:37 PM
» Replies: 1
» Views: 427
11.6 pointer to pointer t...
Forum: 8.11 Pointer type conversions
Last Post: misra-c
08-10-2026, 12:21 PM
» Replies: 2
» Views: 1,032
What is the UTLR of -1?
Forum: 8.10 The essential type model
Last Post: misra-c
08-10-2026, 12:15 PM
» Replies: 1
» Views: 597
10.3 Clarify if narrower ...
Forum: 8.10 The essential type model
Last Post: misra-c
08-10-2026, 11:57 AM
» Replies: 1
» Views: 508
It 8.12 intended to be so...
Forum: 8.8 Declarations and defnitions
Last Post: misra-c
08-10-2026, 11:50 AM
» Replies: 1
» Views: 455
Rule 0.1.1 Example f4
Forum: 4.0 Language independent issues
Last Post: cgpzs
07-10-2026, 11:07 AM
» Replies: 3
» Views: 723
Rule 6-2-2 Usage of std::...
Forum: 6.6 Statements (C++)
Last Post: misra cpp
25-09-2026, 05:43 PM
» Replies: 1
» Views: 436
M5-0-4 switch over unscop...
Forum: 6.5 Expressions (C++)
Last Post: misra cpp
25-09-2026, 01:00 PM
» Replies: 3
» Views: 536