MISRA Discussion Forums
Portal

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

Username
  

Password
  

  MISRA C:2004 Technical Corrigendum 1
Posted by: david ward - 20-07-2007, 01:31 PM - Forum: MISRA resources - No Replies

Since the publication of MISRA C:2004, the MISRA C Working Group have developed the Exemplar Suite (see separate topic). During the development of the Exemplar Suite, and based on questions raised on this Forum, a number of issues have been identified. This document provides clarification on these issues. The clarifications described by this document are incorporated into the Exemplar Suite release 1.0 dated 17 July 2007.

This document is intended to be used in conjunction with a copy of MISRA C:2004.

Please note: copies of MISRA C:2004 purchased on or after 21 July 2008 are a revised edition that incorporates these changes in the text.



Attached Files
.pdf   MISRA_C2_TC1.pdf (Size: 475.48 KB / Downloads: 34)
Print this item

  READ ME FIRST
Posted by: david ward - 20-07-2007, 01:25 PM - Forum: MISRA C resources - No Replies

This area of the Forum provides downloadable resources associated with MISRA Publications.

Please note that by downloading a resource you accept the licence conditions associated with it.

Further details are given with each file.

Print this item

  Misra-C Coding Rule Divide by Safety Integrity Level
Posted by: liner - 12-07-2007, 11:55 PM - Forum: General Questions - Replies (2)

Hi !!!
I have a question.

I Knew MISRA-C Coding Rule is consist of about 140 Coding Rules.
I Wonder this!
Can We devide 140 MISRA-C Coding Rule by Safety Integrity Level 0,1,2,3,4 ?
If We can do above, Could tell me the way?

Please give us an answer !!

Thank you !!!

Print this item

  MISRA C++ public review
Posted by: david ward - 09-07-2007, 02:37 PM - Forum: Announcements - No Replies

This review has now closed. Thank you to all who participated.

MISRA has been developing a set of guidelines for the use of C++ in critical systems, in a similar manner to those guidelines that were produced for \"C\".

MISRA is pleased to announce that a draft for public comment will be available shortly. To participate in the review, please download the reply formand return it by email, fax or post to MIRA at the address shown at the top of the form. As this form requires a signature to indicate acceptance of the terms of the review, only fully completed and signed copies can be accepted.

We will contact you shortly once the documents are available to send you the drafts and the details of the review process. In the event that this public review is over-subscribed, MISRA reserves the right to restrict availability of the draft, and you will be informed if this is the case.

Print this item

  MISRA C:1998 Rule 58
Posted by: himamsu - 29-06-2007, 03:11 PM - Forum: General Questions - Replies (1)

First, its good to see a forum on MISRA C.

I was trying to understand rule 58 (break in a switch statement) from a control flow perspective. Here is a code snippet.

Code:
FUNC_RESULT aFunction(void)
{
FUNC_RESULT result;
......
......
.......

switch(x)
            {
            case 0:
                  result = checkInitVars();
                   /* If checkInitVars is a success, then call
                    * the startOperation too. Else, break. */
                  if (SUCCESS != result)
                     {
                      /* something not fine here, get out. */
                      break; /* Is the break here OKAY? */
                      }
                
                 /* Initialization is fine, start the job! */
                 result = startOperation();
                 break;

            case 1:
                  result = checkInitVars();
                  if (SUCCESS == result)
                     {
                      result = startOperation();
                      }
                  break;
            
             default:
                    result = FAILED;
                    break;
            }
.....
.....
.....
return (result);
}

I would not want to call 'startOperation()' if my initialization variables are checked and returned to have correct values. In both the cases, the operation is started, only if the variables are correct. In light of that, I would like to know which of the case statement is okay and which are not according to the rule.

Thanks in advance,
Himamsu.

Print this item

  Goto to simulate Exceptions
Posted by: ylehman - 25-06-2007, 11:15 AM - Forum: 6.14 Control Flow - Replies (6)

There is a typical paradign where each routine returns a status, and on every call that status is checked. If the status is not \"OK\" then the function call stops, and returns to the calling function. There too, the functions checks the status and returns to it's caller and so on till as some point some function (the exception handler) checks the status and does something about it.

In this way when a error (exception) happens execution stops at that point and the stack is \"unwound\" till the point that it is handled.

In the \"new\" languages this is achieved using exceptions.

In C there are two typical ways of doing this - the \"return\" method and the \"if\" method;

Code:
status   foo(    )
{
      status st = OK;
  
     st = bar_aaa(   );
     if (st == OK) {
         st = bar_bbb(   ); }
     if (st == OK) {
         st = bar_ccc(   ); }

    return st;
}

Or this

Code:
status   foo(    )
{
      status st = OK;
  
     st = bar_aaa(   );
     if (st != OK) {
            return st;
     }
      
     st = bar_bbb(   );
     if (st != OK) {
            return st;
     }

     st = bar_ccc(   );
     if (st != OK) {
            return st;
     }

  return st;
  }


A much cleaner method that I've been using for many years is as follows:


Code:
status   foo(    )
{
      status st = OK;
  
     st = bar_aaa(   ); ER_CHK(st);
     st = bar_bbb(   ); ER_CHK(st);
     st = bar_ccc(   ); ER_CHK(st);

ER_EXIT:

    return st;

}

ER_CHK is a macro that is defined as follows: (simplified)

Code:
#define ER_CHK(st) if (st != OK) goto ER_EXIT; else ;


However the use of the \"goto\" makes people shudder and point to appropriate section in MISRA - though shall not GOTO

My question

Is such a use of GOTO allowed ?
Justification:

1. The GOTO is hidden in a macro and execution proceeds to a well defined point - this is as structured as the the jump commands behind the f,while, switch - and yes - break statements. It is better than the break since the destination is well known

2. The ER_CHK macro can be viewed as an extension of C

3. It provides a single exit point. This is a major problem in the \"return\" method since if there is a resource to release it needs to be done before each return.

4. The code is MUCH cleaner and robust

5. The actual goto was outlawed because it's use lead to a mess - this use prevents the mess - and is more robust since the programmer does not deal with the \"ifs\" and \"returns\" - so can't introduce bugs by doing it wrongly ( \"=\" vs \"==\" bugs, no bug fogetting the \"return\" or doing cleanup before the return etc.)

6. ER_CHK is actully defined as

Code:
#define ER_CHK(st) if (st != OK)         {write_to_log(__LINE__, __FILE__); goto ER_EXIT; else ;

So the log contains something like

foo1.c (23) status = 3;
foo2.c (125) status = 3;
foo3.c (13) status = 3;

Where a function in foo3.c on line 13 calls a function in foo2.c on line 125 etc.

Even C++, Jave exceptions don't do that !!

The attatched article provides more details and shows an implementation that is CPU and Memory efficient.

Again - the quesion I'm asking is that the use of this mechanism illegal in MISRA ?

Print this item

  Switches, default, and enums
Posted by: ChrisNelson - 24-05-2007, 12:38 PM - Forum: 6.15 Switch Statements - Replies (6)

Rule 15.3 requires every switch to end with a default clause. While this is usually a good idea, it undermines the technique of using enums for switch control and having the compiler catch unused or unhandled values. For example:

Code:
typedef enum {
      red,
      green,
      blue
   } color_t;

   void f(color_t color) {
      switch (color) {
      case red:
         /* do something */
         break;
      case green:
         /* do something */
         break;
   }
Many compilers and certainly most lints will generate a warning when compiling the function f noting that not all enum values are handled. When the typedef and the switch are in different files, this can be quite helpful. When the enum is handled by switches in multiple source files, this structure allows the compiler to catch unmodified switches when a new enum value is added. If there was a default case in this switch, the compiler would not complain.

With that in mind, I suggest that rule 15.3 be revised by adding, \"except where the switch expression is an enum\" to the end. I might also add a advisory rule encouraging switch expressions to be enums.

Any thoughts?

Print this item

  Clarification of Rule 17.4
Posted by: Graham Andrews - 24-04-2007, 12:14 PM - Forum: 6.17 Pointers and Arrays - Replies (13)

According to the description of the rule 17.4:

Quote:Array indexing shall only be applied to objects defined as an array type.
.
Given this I do not understand why the following is allowed:
Code:
uint8_t a[10];
uint8_t *p;

p = a;
p[5] = 0; /* why is this compliant? */
Print this item

  Rule 19.11 clarification request
Posted by: rmgalles - 18-04-2007, 12:50 PM - Forum: 6.19 Preprocessing Directives - Replies (1)

As stated and taken literally, this rule might be interpreted as requiring all identifiers used in any preprocessing directive be derived from a previous #define (is this the meaning of \"macro identifier\")?

Instead, I understand the rule as only requiring all identifiers used in the controlling constant-expression of #if and #elif preprocessing directives to be defined before use (unless the identifier is used as the operand of the defined() operator). However, identifiers used in the replacement-list of a #define preprocessing directive need NOT be \"defined before use\" as they may be ordinary identifiers and not defined by any #define preprocessing directive.

Otherwise, the identifier in a #define preprocessing directive itself could technically be interpreted as not meeting this rule, as the identifier isn't fully defined until after the directive has been processed. Thus, the only practical preprocessing directives covered by this rule appear to be #if and #elif directives.


As such, the rule might be more clearly stated as:

Quote:All identifiers used in the controlling constant expression of #if or #elif preprocessing directives shall be #defined before use, unless the identifier is an operand of the defined() operator.

Is my understanding and restating of the rule correct? Or, does this rule actually expect every identifier, including those in every #define \"macro body\" (replacement-list) to be defined before use (by a previous #define)?

Print this item

  is 'Open C' 'MISRA C' compliant?
Posted by: mukesh - 13-04-2007, 05:05 AM - Forum: General Questions - Replies (1)

Hi friends,

my question is same as the subject line

is 'Open C' 'MISRA C' compliant?

thanks n regards
Mukesh

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,172
» Latest member: jeongsang kim
» Forum threads: 998
» Forum posts: 2,752

Full Statistics

Online Users
There are currently 318 online users.
» 0 Member(s) | 316 Guest(s)
Bing, Google

Latest Threads
Rule 6.2.1: non-inline co...
Forum: 4.6 Basic concepts
Last Post: cgpzs
22-11-2024, 10:11 AM
» Replies: 0
» Views: 38
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
21-11-2024, 01:12 PM
» Replies: 0
» Views: 49
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 400
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 339
model information blocks ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:27 PM
» Replies: 1
» Views: 4,460
MISRA AL SLSF - Rule 043I
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:11 PM
» Replies: 1
» Views: 8,876
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,525
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,707
Signal naming convention ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 07:57 AM
» Replies: 1
» Views: 7,259
Rule 7.0.2: operator cons...
Forum: 4.7 Standard conversions
Last Post: karos
14-10-2024, 08:52 PM
» Replies: 2
» Views: 450