MISRA Discussion Forums - 6.14 Control Flow

Loops violate Rule 14.3

Tue, 02 Jun 2015 10:20:04 +0000

Hello.

In our company, we have developers who uses

Code:
for(;;)

loops. Are these a violation against rule 14.3?

kind regards.

Rule 14.3 and null macros

Wed, 14 Sep 2011 07:20:43 +0000

If a function is sometimes to be included and sometimes omitted, the classic solution is to define it like this:

Code:
#if FnIsWanted

  extern void Fn( void );

#else

  #define Fn( ) 

#endif

As already noted, this falls foul of rule 14.3, though primarily it is a breach of rule 19.4 (what a macro can be defined as).

I can get the the effect I want on my compiler without apparently breaching MISRA rules by using the following alternative:

Code:
#if FnIsWanted

  extern void Fn( void );

#else

  #define Fn( ) do{}while(0)

#endif

However, the body of this do-while is a null (compound) statement, so has my compiler missed a violation?

what means about "Before preprocessing" in Rule[14.3]

Wed, 23 Jun 2010 12:33:02 +0000

"Before preprocessing, a null statement shall only occur on a
line by itself; it may be followed by a comment provided that
the first character following the null statement is a white-space
character." in this rule,why "Before preprocessing"is used as a condition?
Thanks!

Rule 14.3

Wed, 17 Mar 2010 15:50:26 +0000

Hi,
I am running into this rule whenever using in-line assemebly in my blackfin project.

i.e

asm ("ssync;");
or
asm("nop;");

generated the error in ibm logiscope
"A null statements shall only occur on a line by itself, and shall not have any other text on the same line"

I assume this comes from having the two ";" characters on the one line.
But how can i overcome this?

Matthew

14.10 /* no else needed */

Thu, 22 Oct 2009 13:15:11 +0000

In rule 14.10 (all if..... else if constructs shall be terminated with an else clause":

is the /* no else needed */ comment on the single if block with no else a suggestion for use in code, where seems useful?

14.10 Hiding an else if construct

Wed, 10 Sep 2008 12:13:38 +0000

The following

Code:
if ( x < 0 )

{

    log_error(3);

    x = 0;

}

else if ( y < 0 )

{

   x = 3;

}

else

{

/* no change */

}

Can be coded as

Code:
if ( x < 0 )

{

    log_error(3);

    x = 0;

}

else 

{

   if ( y < 0 )

   {

      x = 3;

   }

}

to hide the "else if". Is this OK?

I think the code blocks are semantically identical but the last one does not list the else.

Brian

14.1 There shall be no unreachable code

Wed, 24 Oct 2007 07:27:41 +0000

The wording of 14.1 does not clarify the issue clear enough. I've discussed with several experienced persons and the common of these discussions is, that the questions only can be resolved, if someone ADDS personal interpretations. That cannot be the intension of a rule (text).

Firstly, \"defensive programming\" is not a misra rule. In my opinion this is a severe lack in/on the misra rule set. Although not explicitly defined its used in the rule text of 14.1 and its used in a confusing way: \"Code that can be reached but may never be executed is excluded from the rule (e.g. defensive programming)\".

In my tries to understand this, I refactored this sentence on following part (and nobody out of my discussions with Developers and QA Managers could give me an answer on that):

What is \"code, that can be reached but (may) never be executed\" ?

The provided example does not answer this question, because it shows code that \"exists but never will be reached\".

Maybe it helps to concretesize my intention when I re-word above sentence as follows: \"Is it possible, that code can be reached but not executed ?\"

Thanks in advance

Frank

Macros & 14.3 II

Mon, 22 Oct 2007 14:51:45 +0000

Since, according to http://www.misra-c2.com/forum/viewtopic.php?t=264, the following code is not permitted:

Code:
#if debugging

#define ASSERT(x)    asserttest(x)

#else

#define ASSERT(x)

#endif

void f(int *p)

    {

    ASSERT(p != 0);

    }

How would one make code well formed with respect to assertion macros?

Goto to simulate Exceptions

Mon, 25 Jun 2007 11:15:12 +0000

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 ?

Rationale for no goto, continue but allow break

Wed, 14 Sep 2005 14:55:31 +0000

I know this should have been brought up before, but in reviewing MISRA-2 this passed me by.
Being pedantic, why has the rule on break (14.6) been relaxed and not 14.5 (or 14.4)?
A break in a loop is just a goto!
I have no problem with it, it just smacks of inconsistency.

Code Formatter / Beautifyer for 14.8 and 14.9 ?

Wed, 04 May 2005 11:45:10 +0000

Hi there,

is there any Code Formatter / Beautifyer that reformats C code according to the MISRA rules, e.g. MISRA2 Rule 14.9 or Rule 14.8 or MISRA1 Rule59 ?

I know of artistic style (on sf) but unfortunately it has not the rule

kind regards,
Bernhard.

What about Macros for 14.3?

Mon, 20 Dec 2004 18:59:02 +0000

Expanding upon the example in the MISRA 2004 Standard for 14.3:

#define WHATABOUTTHIS /* Um */ ;
#define ORTHIS
#define ANDTHISTOO /* Well, I, uh... */

void f()
{
; /* OK */
/* Not OK */ ;
;/* Not OK */
WHATABOUTTHIS
ORTHIS;
ANDTHISTOO;
}

Which of the lines with macros, if any, violate the Rule?