<![CDATA[MISRA Discussion Forums - 8.15 Control flow]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 15:13:39 +0000 MyBB <![CDATA[Rule 15.5 and return statements as children of labels]]> https://forum.misra.org.uk/showthread.php?tid=1485 Fri, 29 Mar 2019 13:33:29 +0000 rgamble]]> https://forum.misra.org.uk/showthread.php?tid=1485
Quote:When a return statement is used, it should be the final statement in the compound statement that forms the body of the function.

Consider the following example:

Code:
typedef unsigned uint32_t;
uint32_t ten(uint32_t var) {
    if (var == 10) {
       return 10;
    }
}

I think it is pretty clear that this violates Rule 15.5 as the return statement is a child statement of the body of the if, even though no other statements appear between the return statement and the end of the function. Is this correct?

What then about the following:

Code:
typedef unsigned uint32_t;
uint32_t ten() {
my_label:
    return 10;
}

The return statement is technically a child of the label statement so the "final statement in the compound statement that forms the body of the function" is a label statement according to the grammar of C. Is this intended to be a violation of Rule 15.5?]]>
Quote:When a return statement is used, it should be the final statement in the compound statement that forms the body of the function.

Consider the following example:

Code:
typedef unsigned uint32_t;
uint32_t ten(uint32_t var) {
    if (var == 10) {
       return 10;
    }
}

I think it is pretty clear that this violates Rule 15.5 as the return statement is a child statement of the body of the if, even though no other statements appear between the return statement and the end of the function. Is this correct?

What then about the following:

Code:
typedef unsigned uint32_t;
uint32_t ten() {
my_label:
    return 10;
}

The return statement is technically a child of the label statement so the "final statement in the compound statement that forms the body of the function" is a label statement according to the grammar of C. Is this intended to be a violation of Rule 15.5?]]> <![CDATA[Rule 15.7 and empty else statements without "else if"]]> https://forum.misra.org.uk/showthread.php?tid=1381 Tue, 17 Oct 2017 13:36:52 +0000 rgamble]]> https://forum.misra.org.uk/showthread.php?tid=1381 comment." Does "The else statement" refers to any else statement or just the final else statement that is required
by the rule when there are one or more "else if" statements? Is the following example a violation of Rule 15.7 because the else
statement does not contain a side effect or comment or is it compliant because the else is not required by the rule?

Code:
typedef _Bool bool_t;
void foo(bool_t x);
void foo(bool_t x) {
    if (x) {
        ;
    }  
    else { }
}
]]> comment." Does "The else statement" refers to any else statement or just the final else statement that is required
by the rule when there are one or more "else if" statements? Is the following example a violation of Rule 15.7 because the else
statement does not contain a side effect or comment or is it compliant because the else is not required by the rule?

Code:
typedef _Bool bool_t;
void foo(bool_t x);
void foo(bool_t x) {
    if (x) {
        ;
    }  
    else { }
}
]]> <![CDATA[Rule 15.7, 16.4, side-effects and statements.]]> https://forum.misra.org.uk/showthread.php?tid=1330 Tue, 04 Apr 2017 12:04:30 +0000 RichardC]]> https://forum.misra.org.uk/showthread.php?tid=1330
In my opinion, there is a slight inconsistency between the rule rationale for 15.7 and 16.4 and what might be read as being covered.

Starting with Rule 15.7, the amplification requires a side-effect or a comment. Would you agree that this interpretation results in the following examples being 'non-compliant'?

Code:
void f1 (int x, int y)
  {
    for (int i = 0; i < 10; ++i)
    {
      if (i % x )
      {
      }
      else if (i % y)
      {
      }
      else
      {
        break;
      }
      /* Non-Compliant? Not a side-effect and not a comment */
    }
  }

  void f2 (int x, int y)
  {
    if (x != 0)
    {
    }
    else if (y != 0)
    {
    }
    else
    {
      return;
    }
    /* Non-Compliant? Not a side-effect and not a comment.
     * Non-compliant to advisory 15.5 */
  }

  void f3 (int x, int y)
  {
    if (x != 0)
    {
    }
    else if (y != 0)
    {
    }
    else
    {
      ;
    }
    /* Non-Compliant? Not a side-effect and not a comment. */
  }

  void f4 (int x, int y)
  {
    if (x != 0)
    {
    }
    else if (y != 0)
    {
    }
    else
    {
      goto END;
    }
    /* Non-Compliant? Not a side-effect and not a comment. */

  END:
    ;
  }

  void f5 (int x, int y)
  {
    for (int i = 0; i < 10; ++i)
    {
      if (i % x)
      {
      }
      else if (i % y)
      {
      }
      else
      {
        if (i != x)
        {
          if (i != y)
          {
            if ((i*i) > (x*y))
            {
            }
          }
        }
      }
      /* Non-Compliant? No comment or side-effect */
    }
  }

And the following examples would be compliant:

Code:
void f6 (int x, int y)
  {
    if (x != 0)
    {
    }
    else if (y != 0)
    {
    }
    else
    {
      /* Compliant */
    }
  }

  void f7 (int x, int y)
  {
    if (x != 0)
    {
    }
    else if (y != 0)
    {
    }
    else
      /* Compliant, but Non-Compliant with 15.6 */ ;
  }

  void f8 (int x, int y)
  {
    for (int i = 0; i < 10; ++i)
    {
      if (i % x)
      {
      }
      else if (i % y)
      {
      }
      else
      {
        if (i != x)
        {
          if (i != y)
          {
            if ((i*i) > (x*y))
            {
              /* Compliant? Comment "appears" in else. */
            }
          }
        }
      }
    }
  }

For Rule 16.4, the amplification requires a 'statement'. What do you feel is that status of the following examples?

Code:
void f9 (int x)
  {
    switch (x)
    {
    case 0:
      x+=1;
      break;
    case 1:
      x+=2;
      break;
    case 3:
      x+=3;
      break;
    default:
      ;
      break;
    }
    /* Compliant? Is ';' a statement? */

  }

  void fA (int x)
  {
    switch (x)
    {
    case 0:
      x+=1;
      break;
    case 1:
      x+=2;
      break;
    case 3:
      x+=3;
      break;
    default:
      { }
      break;
    }
    /* Compliant? Depends on interpretation of 16.1 regarding { } is a compound statement */
  }

  void fB (int x)
  {
    switch (x)
    {
    case 0:
      x+=1;
      break;
    case 1:
      x+=2;
      break;
    case 3:
      x+=3;
      break;
    default:
      { { } }
      break;
    }
    /* Compliant? Similar to fA */
  }

  void fC (int x)
  {
    switch (x)
    {
    case 0:
      x+=1;
      break;
    case 1:
      x+=2;
      break;
    case 3:
      x+=3;
      break;
    default:
      /* Compliant */
      break;
    }
  }

My reading of the Rationale is that the goal is have a 'defensive' comment unless the else does something, ie. the comment acts as a form of "Annotation".


Alternatively, going just from the rationale, I would mark the above functions as Compliant/Non-Compliant as follows:
  • f1: Compliant
  • f2: Compliant, Non-Compliant with rule 15.5.
  • f3: Non-Compliant
  • f4: Compliant
  • f5: Compliant
  • f6: Compliant
  • f7: Compliant, Non-Compliant with Rule 15.6
  • f8: Compliant (not because of nested comment)
  • f9: Non-Compliant
  • fA: Non-Compliant
  • fB: Compliant

What is the view of the MISRA C group on this?]]>
In my opinion, there is a slight inconsistency between the rule rationale for 15.7 and 16.4 and what might be read as being covered.

Starting with Rule 15.7, the amplification requires a side-effect or a comment. Would you agree that this interpretation results in the following examples being 'non-compliant'?

Code:
void f1 (int x, int y)
  {
    for (int i = 0; i < 10; ++i)
    {
      if (i % x )
      {
      }
      else if (i % y)
      {
      }
      else
      {
        break;
      }
      /* Non-Compliant? Not a side-effect and not a comment */
    }
  }

  void f2 (int x, int y)
  {
    if (x != 0)
    {
    }
    else if (y != 0)
    {
    }
    else
    {
      return;
    }
    /* Non-Compliant? Not a side-effect and not a comment.
     * Non-compliant to advisory 15.5 */
  }

  void f3 (int x, int y)
  {
    if (x != 0)
    {
    }
    else if (y != 0)
    {
    }
    else
    {
      ;
    }
    /* Non-Compliant? Not a side-effect and not a comment. */
  }

  void f4 (int x, int y)
  {
    if (x != 0)
    {
    }
    else if (y != 0)
    {
    }
    else
    {
      goto END;
    }
    /* Non-Compliant? Not a side-effect and not a comment. */

  END:
    ;
  }

  void f5 (int x, int y)
  {
    for (int i = 0; i < 10; ++i)
    {
      if (i % x)
      {
      }
      else if (i % y)
      {
      }
      else
      {
        if (i != x)
        {
          if (i != y)
          {
            if ((i*i) > (x*y))
            {
            }
          }
        }
      }
      /* Non-Compliant? No comment or side-effect */
    }
  }

And the following examples would be compliant:

Code:
void f6 (int x, int y)
  {
    if (x != 0)
    {
    }
    else if (y != 0)
    {
    }
    else
    {
      /* Compliant */
    }
  }

  void f7 (int x, int y)
  {
    if (x != 0)
    {
    }
    else if (y != 0)
    {
    }
    else
      /* Compliant, but Non-Compliant with 15.6 */ ;
  }

  void f8 (int x, int y)
  {
    for (int i = 0; i < 10; ++i)
    {
      if (i % x)
      {
      }
      else if (i % y)
      {
      }
      else
      {
        if (i != x)
        {
          if (i != y)
          {
            if ((i*i) > (x*y))
            {
              /* Compliant? Comment "appears" in else. */
            }
          }
        }
      }
    }
  }

For Rule 16.4, the amplification requires a 'statement'. What do you feel is that status of the following examples?

Code:
void f9 (int x)
  {
    switch (x)
    {
    case 0:
      x+=1;
      break;
    case 1:
      x+=2;
      break;
    case 3:
      x+=3;
      break;
    default:
      ;
      break;
    }
    /* Compliant? Is ';' a statement? */

  }

  void fA (int x)
  {
    switch (x)
    {
    case 0:
      x+=1;
      break;
    case 1:
      x+=2;
      break;
    case 3:
      x+=3;
      break;
    default:
      { }
      break;
    }
    /* Compliant? Depends on interpretation of 16.1 regarding { } is a compound statement */
  }

  void fB (int x)
  {
    switch (x)
    {
    case 0:
      x+=1;
      break;
    case 1:
      x+=2;
      break;
    case 3:
      x+=3;
      break;
    default:
      { { } }
      break;
    }
    /* Compliant? Similar to fA */
  }

  void fC (int x)
  {
    switch (x)
    {
    case 0:
      x+=1;
      break;
    case 1:
      x+=2;
      break;
    case 3:
      x+=3;
      break;
    default:
      /* Compliant */
      break;
    }
  }

My reading of the Rationale is that the goal is have a 'defensive' comment unless the else does something, ie. the comment acts as a form of "Annotation".


Alternatively, going just from the rationale, I would mark the above functions as Compliant/Non-Compliant as follows:
  • f1: Compliant
  • f2: Compliant, Non-Compliant with rule 15.5.
  • f3: Non-Compliant
  • f4: Compliant
  • f5: Compliant
  • f6: Compliant
  • f7: Compliant, Non-Compliant with Rule 15.6
  • f8: Compliant (not because of nested comment)
  • f9: Non-Compliant
  • fA: Non-Compliant
  • fB: Compliant

What is the view of the MISRA C group on this?]]> <![CDATA[15.7 and side effects]]> https://forum.misra.org.uk/showthread.php?tid=1217 Fri, 11 Dec 2015 00:08:34 +0000 lovewar]]> https://forum.misra.org.uk/showthread.php?tid=1217
Code:
void R_15_7 ( void ) {
   bool_t flag_1 = get_bool ( );
   bool_t flag_2 = get_bool ( );
   if ( flag_1 )  {
      action_f1 ( );
   }
   else if ( flag_2 )  {
      action_f2 ( );
   }
   else {  // here , is the "else" compliant ?
      persistent_side_effects();
  }
}

Would the following examples be compliant with rule #15.7?
Code:
void R_15_7 ( void ) {
   bool_t flag_1 = get_bool ( );
   bool_t flag_2 = get_bool ( );
   if ( flag_1 )  {
      action_f1 ( );
   }
   else if ( flag_2 )  {
      action_f2 ( );
   }
   else {  // here , is the "else" compliant ?
      side_effects();
  }
}

Would the following examples be non-compliant with rule #15.7?
Code:
void R_15_7 ( void ) {
   bool_t flag_1 = get_bool ( );
   bool_t flag_2 = get_bool ( );
   if ( flag_1 )  {
      action_f1 ( );
   }
   else if ( flag_2 )  {
      action_f2 ( );
   }
   else {  // here, is the "else" non-compliant ?
      no_side_effects();
  }
}
]]>
Code:
void R_15_7 ( void ) {
   bool_t flag_1 = get_bool ( );
   bool_t flag_2 = get_bool ( );
   if ( flag_1 )  {
      action_f1 ( );
   }
   else if ( flag_2 )  {
      action_f2 ( );
   }
   else {  // here , is the "else" compliant ?
      persistent_side_effects();
  }
}

Would the following examples be compliant with rule #15.7?
Code:
void R_15_7 ( void ) {
   bool_t flag_1 = get_bool ( );
   bool_t flag_2 = get_bool ( );
   if ( flag_1 )  {
      action_f1 ( );
   }
   else if ( flag_2 )  {
      action_f2 ( );
   }
   else {  // here , is the "else" compliant ?
      side_effects();
  }
}

Would the following examples be non-compliant with rule #15.7?
Code:
void R_15_7 ( void ) {
   bool_t flag_1 = get_bool ( );
   bool_t flag_2 = get_bool ( );
   if ( flag_1 )  {
      action_f1 ( );
   }
   else if ( flag_2 )  {
      action_f2 ( );
   }
   else {  // here, is the "else" non-compliant ?
      no_side_effects();
  }
}
]]> <![CDATA[Rule 15.5]]> https://forum.misra.org.uk/showthread.php?tid=1098 Wed, 13 Aug 2014 10:13:47 +0000 Mandar_Pitale]]> https://forum.misra.org.uk/showthread.php?tid=1098
The Rationale of this rule says:

Early returns may lead to the unintentional omission of function termination code.

1. What is "function termination code" in this context? Does it mean user defined C statements of the function or the function epilogue after the compilation?

2. If it is the function epilogue, then does it mean that when multiple exit points are used, then it MAY result in imbalanced context retrieval when the function returns, for some compilers?]]>
The Rationale of this rule says:

Early returns may lead to the unintentional omission of function termination code.

1. What is "function termination code" in this context? Does it mean user defined C statements of the function or the function epilogue after the compilation?

2. If it is the function epilogue, then does it mean that when multiple exit points are used, then it MAY result in imbalanced context retrieval when the function returns, for some compilers?]]> <![CDATA[Rule 15.3 Example]]> https://forum.misra.org.uk/showthread.php?tid=1021 Tue, 21 Jan 2014 10:09:59 +0000 ogawa.kiyoshi]]> https://forum.misra.org.uk/showthread.php?tid=1021 void f1(int32_t a){
if ( a 0){
L2:
;
}
}
has some unreachable codes. So I think
void f1(int32_t a){
if ( a 0){
L2:
;
}
}
are enough and no unreachable codes.

Dr. Ogawa Kiyoshi
https://twitter.com/kaizen_nagoya/, http://researchmap.jp/kaizen/MISRA-C/]]> void f1(int32_t a){
if ( a 0){
L2:
;
}
}
has some unreachable codes. So I think
void f1(int32_t a){
if ( a 0){
L2:
;
}
}
are enough and no unreachable codes.

Dr. Ogawa Kiyoshi
https://twitter.com/kaizen_nagoya/, http://researchmap.jp/kaizen/MISRA-C/]]> <![CDATA[Rule 15.3, switch's, and "fallthru"]]> https://forum.misra.org.uk/showthread.php?tid=1002 Tue, 10 Dec 2013 16:59:28 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=1002 this rule?
Code:
...
switch( a )
{
case 1:
    if( f(a) > 8 )
        goto b;
    doingSomething();
case 2:
    doingSomeOtherThing();
b:
    tada( a );
    break;
default:
    break;
}
...
]]> this rule?
Code:
...
switch( a )
{
case 1:
    if( f(a) > 8 )
        goto b;
    doingSomething();
case 2:
    doingSomeOtherThing();
b:
    tada( a );
    break;
default:
    break;
}
...
]]> <![CDATA[Does rule #15.3 apply to all blocks or only control blocks?]]> https://forum.misra.org.uk/showthread.php?tid=956 Tue, 09 Apr 2013 14:49:57 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=956
Code:
void f()
{
    {
    goto L1;
    }
    {
L1:
    }
}

Does this code violate rule #15.3?]]>
Code:
void f()
{
    {
    goto L1;
    }
    {
L1:
    }
}

Does this code violate rule #15.3?]]>