Welcome to the MISRA discussion forum

This document has now been superseded by MISRA Compliance:2016. The following description is retained for archival purposes.

MISRA is pleased to announce the availability of an additional resource for MISRA C, MISRA C ADC Approved deviation compliance for MISRA C:2004.

MISRA C is intended to be used within the framework of a disciplined software development process. The MISRA C:2004 guidelines (Section 4.3.2) permit controlled deviation from the rules when software safety and/or quality requirements cannot otherwise be satisfied.

It should be understood that a deviation can only be adequately justified when supported by information such as:

• An appropriate reason for the need to raise a deviation;
  
• A description of the extent to which a relaxation of the rule is being introduced;
  
• An argument to support the reasons for the deviation;
  
• Measures which must be observed to ensure safety and/or quality.

This document has now been superseded by MISRA Compliance:2016. The following description is retained for archival purposes.

MISRA C is intended to be used within the framework of a disciplined software development process. The MISRA C:2004 guidelines (Section 4.3.2) permit controlled deviation from the rules when software safety and/or quality requirements cannot otherwise be satisfied.

It should be understood that a deviation can only be adequately justified when supported by information such as:

• An appropriate reason for the need to raise a deviation;
  
• A description of the extent to which a relaxation of the rule is being introduced;
  
• An argument to support the reasons for the deviation;
  
• Measures which must be observed to ensure safety and/or quality.

MISRA is very pleased to announced today at Embedded World that the next edition of MISRA C Guidelines for the use of the C language in critical systems, to be known as MISRA C:2012, will be available from the MISRA webstore from 18 March 2013. Initially PDF copies will be available to purchase, with print copies available about 2 weeks later.

MISRA C:2012 extends support to the C99 version of the C language (while maintaining guidelines for C90), in addition to including a number of improvements that can reduce the cost and complexity of compliance, whilst aiding consistent, safe use of C in critical systems. Improvements, many of which have been made as a result of user feedback, include: better rationales for every guideline, identified decidability so users can better interpret the output of checking tools, greater granularity of rules to allow more precise control, a number of expanded examples and integration of MISRA AC AGC. A cross reference for ISO 26262 has also been produced.

Check back here for further details or subscribe to the MISRA mailing list to stay informed.

See 14-7-3 Example:

a function template specialization for good_tmp1 violated ODR in tmp1.cc.

It seems that the 8.7 rule contradict design for testability.
Infact when you have a static variabile defined at block level, right now you have no way to perform any white box testing withot changing/adding code to copy the value to a global variable.

Let me know

Giacomo

• MISRA C rule 17.4 says arithmetic operations shall not be performed on pointers, as they may result into referencing to non-existing addresses.
• Alternative to this is to catch a pointer being received as an argument into the respective type of an array, for e.g. catch ‘&arr’ into ‘arr[]’, and use array indexing to access its elements. This works well for pointers of basic data types.
• Problem arises in the case of accessing array elements contained by a structure.
• e.g.
struct message
{
int address;
int length;
int data[50];
}m1,m2;

• Now, the statement “source_node = m1.data[SOURCE_NODE_INDEX]” triggers this 17.4 non-compliance note.
• This happens when accessing only the array elements, and not for single variables of a structure definition.
• So the question I have is, what is the best way to access individual array elements contained inside a structure definition?

I have recently received a question from a customer using our code generation tools (embedded coder).
The code that we generate for a block (saturate block) is like this:

Hi

As I understand it, rule 3.1 is a "catch all" rule that addresses all of the implementation-defined behaviour not addressed by the other rules. However, MISRA-C:2004 does not explicitly list all of those issues, so it is not possible to tell at a glance exactly what falls under rule 3.1. This creates some difficulty determining the extent to which our static analysis software enforces the MISRA rules, and therefore also when enforcing the delta with manual review.

I could draw up a list of those issues using MISRA-C:2004 Appendix G as a guide to determining which of the issues in ISO/IEC 9899:1990 Appendix G are addressed by other rules, and seeing what is left. I could do this, but it is not a 5-minute exercise (for me) and I suspect that this work has already been done many times before now.

Has a list like that been published on the web anywhere? I've tried googling for it, but to no avail.

Kind regards
Michael

An identifier with external linkage shall have exactly one definition.
The test exemplar provided with MISRA C for rule 8.9 has
// mc2_0809_1.c
int32_t two_different_definitions = 1; /* Not Compliant - two definitions */
// mc2_0809_2.c
int32_t two_different_definitions = 2; /* Not Compliant - two definitions */
// mc2_0809.h
extern int32_t two_different_definitions;

But the example given in the MISRA C++ Guidelines Draft for Rule 3-2-4 is :
// file1.cpp
int32_t i = 0;
// file2.cpp
int32_t i = 1; // Non-compliant

As both the rules are some what same, but the difference in the example given is that in rule 3-2-4 no external linkage is provided. Is it an incomplete example or the rule should show violation without having an extern of the variable.

Hi,

I missed discussion about new Misra C to be released.
Anyway now and then I have several questions and comments about dynamic memory allocation.

In Misra C 2004 there is only one rule (20.4) addressing dynamic memory allocation.
In my opinion it's too little. There are questions not answered by this single rule.

So the questions are:
1. Is this rule only forbiding use of malloc, calloc, realloc and free functions while leaving a room for implementation and use of prorpietary functions?

2. Is proprietary dynamic memory management allowed in any way?

3. I would like to implement my own "heap" (pool) which would allow for memory allocation on startup only and no deallocation anytime. Is this possible without violation of this rule?

In my opinion these questions should be answered in new Misra in some clearer way.

Best regards,
Szymon