13.5 Loop control expression inconsistencies

6.13 Control Statement Expressions

Moderators: misra-c, david ward

Post Reply
Posts: 1
Joined: Tue Jan 24, 2012 8:54 am
Company: SonarSource

13.5 Loop control expression inconsistencies

Post by Dinesh » Wed May 30, 2012 11:19 am

Dear Misra Committee,

Going through the previous posts on the rule 13.5, I found an inconsistency between the answers given in:
1) http://www.misra.org.uk/forum/viewtopic.php?f=69&t=272
2) http://www.misra.org.uk/forum/viewtopic.php?f=69&t=874

In the first post, the following was posted:
Loop Control Variable is defined as any variable occurring in the first, second or third expressions.

Loop Counter is defined as a Loop Control Variable which is,
• Initialised in the first expression or Initialised prior to first expression;
• In the second expression, the operand of a relational operator (<=, <, >, >= ); Note (1)
• In the third expression, always incremented or decremented by a constant, or an expression which evaluates to the same value for the duration of the loop;
• Not modified in the body of the loop.
Note 1: The equality operators (==, !=) should not be used because termination of the loop may not occur.
In the second post, the following example was given and was confirmed to be compliant with MISRA C 13.5.

Code: Select all

bool Test_Index(int32_t index, int32_t bound){
   return (bool)(p<bound);

void bar(void){
   int32_t i;

   for (i=0;Test_Index(i, 100);i++){  /* i is tested outside the for loop. Does is comply to Misra philosophy ? */
It is clear that the expression "Test_Index(i, 100)" does not contain any relational operator.
Therefore, there is no loop counter, as per the definition given in the first post.

As a consequence, the loop counter cannot be incremented or decremented in the third expression, as this very loop counter does not exist.
I therefore conclude that the code snippet is *not* compliant with MISRA 13.5, which contradicts the answer given in the second topic.

All this to say that I disagree with the answers given to the second post, because:
• From a user perspective, the code is still hard to understand
• It does not comply with the previous definitions
• From a tool vendor perspective, it also becomes much more costly (both in terms of implementation and runtime performances) to verify this rule.

This also raises a question: Should the answers of this forum be considered as normative?

Posts: 572
Joined: Thu Jan 05, 2006 1:11 pm

Re: 13.5 Loop control expression inconsistencies

Post by misra-c » Mon Jun 18, 2012 6:59 pm

Firstly, official answers given in this forum are normative. However, as with other standards and guidelines, this does not mean that they are necessarily error-free. As experience is gained with using the guidelines, it may be necessary to post corrections to both the original guidelines and postings in this forum.

Your question rightly identifies a discrepancy between two answers given in this forum. The source of the discrepancy is the answer given in 2005 to the posting viewtopic.php?f=69&t=272. In this answer, it was stated that a Loop Counter is the operand of a relational operator in the second expression of the for statement. This should instead have stated that a Loop Counter is involved in the decision to terminate the loop in the second expression of the for statement.

This weaker requirement on Loop Counters would then allow i, as used in the response to viewtopic.php?f=69&t=874, to be defined as a Loop Counter provided that the value returned by TestIndex depends its first parameter.
Posted by and on behalf of
the MISRA C Working Group

Post Reply

Return to “6.13 Control Statement Expressions”