Is there any MISRA rule to find this sideeffect??

[sprabhakars]

I am not sure, if this potential problem is categorized under any MISRA rules??

Code:

#include
static unsigned short var2;
int main()
{
       unsigned char var1 = 0;

       while (var1 <  var2)
       {
          var1++;
       }
       (void)printf("program completed \n ");
       return 0;
}

The variable var2 can have some value updated outside this function(may be more than 256) and causing a system crash as the while condition never fails.

I run this with PC-Lint and Parasoft's MISRA checker, both doesn't find any error with this portion of code.

[dg1980]

Quote from amplification of rule 9.1:

According to The Standard, objects with static storage duration are automatically initialized to zero

[sprabhakars]

I just re edited the code for better clarity -
I am not sure, if this potential problem is categorized under any MISRA rules??

Code:

#include
int main()
{
       unsigned char var1 = 0;
       unsigned short var2 =  300;
      
       while (var1 <  var2)
       {
          var1++;
       }
       (void)printf("program completed \n ");
       return 0;
}

The variable var2 shall be greater than var1(var1 is a char and var2 is short) and may not breaks out of this while the while condition never fails.

I run this with PC-Lint and Parasoft's MISRA checker, both doesn't find any error with this portion of code.

[dg1980]

Unfortunately, both operands to < are "essentially unsigned" so none of the 10.x rules is violated.
The printf/return statements however violate rule 2.1 "unreachable code".
But as you already witnessed, that is difficult to track down during static analysis (the code needs to be executed during analysis).

[Francois]

Hi
Isn't there a rule to ensure that comparison is perform on same object type?

[dg1980]

Hi
Isn't there a rule to ensure that comparison is perform on same object type?

Check the table in MISRA C 2012 Appendix D.1: both operands are essentially unsigned.
The table in rule 10.1 poses no restrictions on operator < for essentially unsigned operands.
If both operands are supposed to be of the same essential type (not just the same essential type category): that is not clearly stated IMHO.
IMHO, currently the bug would be catched only if there is a narrowing assignment which is prohibited by rule 10.3 (see below).
Anyhow, an official clarification would be nice.

Code:

#include

int main(void)
{
  unsigned char var1 = 0;
  unsigned short var2 =  300;
  const unsigned char cmp = var2;/*Expression assigned to a narrower or different essential type [MISRA 2012 Rule 10.3, required]*/

  while (var1 <  cmp)
  {
    var1++;
  }
  (void)printf("program completed \n ");
  return 0;
}

[misra-c]

Thank you for drawing this to our attention... this appears (at first glance) to have found a gap in our guidelines!

The MISRA C Working Group will look into this further and post an update in due course...