MISRA Discussion Forums
Portal

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

Username
  

Password
  

  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

  Initialize a tag?
Posted by: gs - 21-03-2007, 04:16 PM - Forum: General Questions - No Replies

1998 Rule 29 states, \"[i]t would be incorrect to initialize the tag with an initializer which did not match the structure declared for that tag.\"

What does it mean to \"initialize the tag\"?

Print this item

  Rule 45 and polymorphism
Posted by: jlb - 07-03-2007, 03:10 PM - Forum: 6.11 Pointer Type Conversions - Replies (3)

Hello,

I am new to MISRA-C rules and in the code I am working on, there this kind of constructs :

Code:
struct TPL_ACTION {
    tpl_action_func action;    /**<  action function pointer   */
};

typedef struct TPL_ACTION tpl_action;

and for instance :

Code:
struct TPL_TASK_ACTIVATION_ACTION {
    /*  base action           */
    tpl_action    b_desc;
    /*  task descriptor pointer     */
    tpl_task      *task;
};

typedef struct TPL_TASK_ACTIVATION_ACTION
tpl_task_activation_action ;

tpl_action is an abstract type (no instance) and tpl_task_activation_action is a concrete type.

The function pointed by action function pointer takes a tpl_action * and casts it to the appropriate concrete type.

I understand rule 45 disallows pointer type casting to avoid memory alignment problems but here the first member of the abstract type is of the same type as the first member of the concrete type.

Is it legal ?

Best regards

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 58 online users.
» 0 Member(s) | 54 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: 426
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: 719
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: 435
M5-0-4 switch over unscop...
Forum: 6.5 Expressions (C++)
Last Post: misra cpp
25-09-2026, 01:00 PM
» Replies: 3
» Views: 532