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

Username
  

Password
  





  MISRA C:2012 permits
Posted by: david ward - 01-03-2021, 01:22 PM - Forum: MISRA resources - No Replies

No sooner had the MISRA C:2004 Permits been published, the question was asked “When will MISRA C:2012 Permits be published?” The wait is now over ...

MISRA C:2012 Permits provides a set of permits to aid compliance, particularly in the lower-levels (e.g. hardware access), but also to make compliance easier where automatically generated code is being created.

A related Guideline Reclassification Plan for Automatically Generated Code is being worked on, and will be released in due course.

This document presents a number of deviation permits covering commonly-encountered use cases for use with the MISRA C:2012 guidelines. It should be used in conjunction with MISRA Compliance:2020, a companion document which describes the purpose of deviation permits and which sets out the principles by which the concept of MISRA Compliance is governed.

The number of deviation permits within this document is expected to grow and it is possible that existing deviation permits may be revised. The document contains a table with a record of these changes.

The current release is Edition 1, published March 2021.



Attached Files
.pdf   MISRA C 2012 Permits (First Edition).pdf (Size: 812.01 KB / Downloads: 30)
Print this item

  6-5-4: on variable or expression?
Posted by: Nadege - 29-01-2021, 11:06 AM - Forum: 6.6 Statements (C++) - Replies (1)

Hello,

6-5-4 says "The loop-counter shall be modified by one of: --, ++, - = n, or + = n; where n remains constant for the duration of the loop"

Should this code below raise 6-5-4?

int main() {
int k = 8;

for (int j = 0; j < 10; j += k + 3) {
}
}

If 'n' concerns variable only, I would say 'Yes'.
If 'n' concerns expressions, I would say 'No'.

What do you think?
Thanks in advance for your help.

Nadège

Print this item

  MISRA AC guidelines public review Jan 21
Posted by: david ward - 22-01-2021, 04:34 PM - Forum: MISRA AC GMG discussions - No Replies

MISRA is pleased to announce that drafts of new versions of its Autocode documents MISRA AC GMG "Generic Modelling Design and Style Guidelines" and MISRA AC SLSF "Modelling Design and Style Guidelines for the Application of Simulink and Stateflow" will shortly be available for public review.

The revision process has focused on the following:

  • Addressing feedback raised on the previous versions
  • Seeking to reduce areas of ambiguity and inconsistency
  • Updating SLSF for more recent revisions of the MathWorks toolset with expanded capabilities and, in some areas, modelling semantics
  • Further clarifying and extending Stateflow usage guidelines to define more tightly a standardized usage style from a subset of Stateflow’s capabilities

If you would like to be considered as a reviewer please download the attached file and return it to us via email. We will review applications and be in touch with next steps in due course. Please note that in the case of high levels of interest we may not be able to accept all offers of reviews.

Updated Feb 2021. The call for reviewers is now closed and we will be sending out the review package shortly. Thank you to everyone that has expressed interest

Print this item

  Rule 10.4 and essentially signed integer constant expressions
Posted by: jaska - 19-01-2021, 02:34 PM - Forum: 8.10 The essential type model - No Replies

Rule 10.3 exception 1 allows assigning a signed integer constant expression to an essentially unsigned type, if the value can be represented in that type; u8 = 2 * 24; is allowed.
Rule 10.4 has no such exception
Expressions like u32 > 0, u8 != 0, and u32 += 1 violate rule 10.4.

Now:

uint32_t u32idem(uint32_t x) { return x; }
bool less_u32(uint32_t a, uint32_b ) { return a < b; }

if (u32 < u32idem(1)) { /* accepted by 10.3 and 10.4 */
} else if (less_u32(u32, 3)) { /* accepted by 10.3 (and 10.4) */
} else if (u32 < 4u) { /* fine by 10.4 */
} else if (u32 < 7) { /* violates 10.4 */
} else if (11u > u32) { /* ok, remove u and it's not */
} else {
switch (u32) {
case 23: /* ok */
...

Why are binary operators handled differently from assignments and switch cases? I think the exception should be the same for both 10.3 and 10.4 ?

Why is there no exception for Rule 10.4 allowing an integer constant expression to be used in a binary expression?

Print this item

  10.4 violation for u8b + 2
Posted by: fmteau - 18-01-2021, 01:27 PM - Forum: 8.10 The essential type model - Replies (2)

Hello MISRA Bulletin Board,

I understand mixing signed and unsigned variables in arithmetic operations can really lead to unexpected results,
but I really fail to see what is the risk in adding a constant value of 2 (SLTR of signed char) to an unsigned 8-bit (char) variable.

Could you please elaborate what can possibly go wrong in this case?

Thanks in advance.

Print this item

  No operators in #if
Posted by: John C - 17-12-2020, 08:29 AM - Forum: 8.10 The essential type model - Replies (8)

The MISRA checker I am using is rejecting operators in #if as noted in the following code.

Code:
#define TRUE 1

#define Condition1 TRUE
#define Condition2 TRUE

#if Condition1   /* Accepted */
#endif
#if !Condition1  /* Rejected */
/* Rejection is because:
Unpermitted operand to operator '!' [MISRA 2012 Rule 10.1, required]
*/
#endif
#if Condition1 && Condition2  /* Rejected */
/* Rejection is because:
Unpermitted operand to operator '&&' [MISRA 2012 Rule 10.1, required]
*/
#endif
#if Condition1 || Condition2  /* Rejected */
/* Rejection is because:
Unpermitted operand to operator '||' [MISRA 2012 Rule 10.1, required]
*/
#endif
According to the supplier, the constant '1' (or '0' when used in the same way) is being interpreted as a signed int and therefore the operators '!', '&&' and '||' cannot be used with it.

Is the checker's interpretation correct?

Print this item

  MISRA C:2012 9.3 clarification
Posted by: mcks - 24-11-2020, 09:19 AM - Forum: 8.9 Initialization - Replies (1)

I try to implement the checks for "9.3 - Arrays shall not be partially initialized" in Cppcheck, and would like to have some clarifications.

Is it ok to mix initializers like this, as long as every element gets initialized?

int32_t a[3] = { 1, 2, [2]=3 };

For multi-dimensional arrays, this would be compliant:

int32_t b[2][2] = { { 1, 2 }, { [1]=4 } };

beacuse b[1] is initialized with only a designated initializer.


As for c, both the array subobjects c[0] and c[1] are fully initialized, but there is no initialization of c[2]. Does that make the statement non-compliant?

int32_t c[3][2] = { { 1, 2 }, { 3, 4 } };


What about the arrays below, are they compliant or not, and why? Also, are they violatin 9.2 or 9.4?
int32_t d[1][2] = { [0][1]=2, [0]={1} };
int32_t e[1][2] = { [0]={1}, [0][1]=2 };
int32_t f[3][2] = { [1]={3, 4}, { 5, 6 }, [0][1]=2, [0][0]=1 };
int32_t g[2][2] = { { 1, 2 }, [1][0]=3, 4 };

Let me know what you think. If you have more (tricky) examples, then please share!

Print this item

  Rule 0-1-11 and postfix increment/decrement operators
Posted by: rrosier - 19-11-2020, 04:29 PM - Forum: 6.0 Language independent issues (C++) - Replies (2)

Rule 0-1-11 states that there shall be no unused parameters (named or unnamed) in a non-virtual function.

However, when writing a postfix increment/decrement operator, the C++ standard states:

Quote:If the function is a member function with one parameter (which shall be of type int) or a non-member function with two parameters (the second of which shall be of type int), it defines the postfix increment operator ++ for objects of that type.
...
The prefix and postfix decrement operators -- are handled analogously.

Such operators are then written as:

Code:
struct X {
  X operator++(int); // postfix a++
};

On the face of it, this seems to violate Rule 0-1-11, because the unnamed int parameter is unused.

Is this an real violation, so that in order to write postfix increment/decrement operators we have to deviate, or is this rule not intended to apply in such cases where the C++ standard itself is defining that the parameter is unused (and therefore any flagging of such code is a false positive)?

I cannot find any direct prohibition of the writing of postfix increment/decrement operators elsewhere in the MISRA rules, so it surprises me that this rule appears to prohibit their use in this roundabout fashion.

Print this item

  Rule 0-1-6 and Boolean variables
Posted by: LordMordac - 18-11-2020, 09:50 PM - Forum: 6.0 Language independent issues (C++) - Replies (13)

Rule 0-1-6 seems to be counter productive with Boolean variables. DU dataflow anomalies are normal and desirable with Boolean variables. For example:

Code:
extern bool random_bool ();

bool non_compliant_and (void)
{
    bool const b1 = random_bool();
    bool const b2 = random_bool();

    return b1 && b2;   // b2 is DU dataflow anomaly when b1 is false
}

bool non_compliant_or (void)
{
    bool const b1 = random_bool();
    bool const b2 = random_bool();

    return b1 || b2;   // b2 is DU dataflow anomaly when b1 is true
}

bool compliant_and (void)
{
    bool const b1 = random_bool();
    bool const b2 = random_bool();

    bool tmp = b1;
    tmp = b2 && b1;

    return tmp;
}

bool compliant_or (void)
{
    bool const b1 = random_bool();
    bool const b2 = random_bool();

    bool tmp = b1;
    tmp = b2 || b1;

    return tmp;
}
The compliant and non-compliant code result in different binaries. Both seem equally safe, but the compliant solution is less efficient. Which seems at odds with the statement in MISRA spec claims
Quote:At best this (DU dataflow anomaly) is inefficient, but may indicate a genuine problem.
Is there any insight anyone can provide on such a perplexing problem?

Print this item

  Misra Rules for cppcheck
Posted by: julred - 04-11-2020, 05:58 AM - Forum: General Questions - Replies (6)

Hi everyone,

I'm using the application cppcheck for my existing development. Now I'd like to add the functionality of checking my sources against Misra rules.
Therefor I need the Misra Rules in a .txt file format. Where can I get it?

BR

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 5,681
» Latest member: DelayShot
» Forum threads: 880
» Forum posts: 2,427

Full Statistics

Online Users
There are currently 76 online users.
» 0 Member(s) | 73 Guest(s)
Bing, Google, Yandex

Latest Threads
MISRA C++ new version
Forum: C++ Announcements
Last Post: david ward
30-11-2021, 03:53 PM
» Replies: 7
» Views: 10,932
CWE Coverage by MISRA
Forum: General Questions
Last Post: susanne.goldammer
30-11-2021, 12:23 PM
» Replies: 0
» Views: 24
Rule8.9 applicability to ...
Forum: 8.8 Declarations and defnitions
Last Post: misra-c
27-11-2021, 11:10 AM
» Replies: 1
» Views: 229
Rule 14.3 and preprocesso...
Forum: 8.14 Control statement expressions
Last Post: misra-c
27-11-2021, 11:00 AM
» Replies: 1
» Views: 151
Rule 17.4 and main
Forum: 8.17 Functions
Last Post: misra-c
27-11-2021, 09:58 AM
» Replies: 1
» Views: 168
2.2 Dead code, 'operation...
Forum: 8.2 Unused code
Last Post: misra-c
27-11-2021, 09:18 AM
» Replies: 1
» Views: 170
for loop iterator being c...
Forum: 8.10 The essential type model
Last Post: misra-c
27-11-2021, 09:10 AM
» Replies: 1
» Views: 184
5-2-12 - Does the rule ap...
Forum: 6.5 Expressions (C++)
Last Post: DavidFriberg
24-11-2021, 03:23 PM
» Replies: 0
» Views: 67
6-5-2 and 6-5-4 on while ...
Forum: 6.6 Statements (C++)
Last Post: cgpzs
18-11-2021, 12:09 PM
» Replies: 4
» Views: 244
A3-1-5 - Rationale and ex...
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
15-11-2021, 08:45 AM
» Replies: 2
» Views: 191