MISRA Discussion Forums - 6.13 Control Statement Expressions

1-bit bitfield in boolean expression

Mon, 22 Jul 2013 08:53:41 +0000

Hi,
rule 13.2 makes an example how boolean data could be used in an expression:

Code:
if ( y ) /* Not compliant, unless y is effectively Boolean data (e.g. a flag) */

The example refers to a Boolean-by-enforcement type referred to in the appendix.
But what is with a 1-bit Bitfield? Is it a Boolean-by-construct?

Code:
struct { unsigned int flag1: 1, flag2: 1;} var;

...

if (var.flag1)                   /* violation of rule 13.2 ? */

if (( var.flag1) && (var.flag2)) /* violation of rule 12.6 ? */

if ((!var.flag1) && (var.flag2)) /* 2x violation of rule 12.6 ? */

if ((var.flag1 == 0) && (var.flag2 != 0)) /* OK, but clumsy and harder to read */

Thanks for a comment!

Rules 13.4 Function call with float

Tue, 25 Jun 2013 14:34:49 +0000

Hello,

As the rule 13.4 says : The controlling expression of a for statement shall not contain any objects of floating type.

But what about a function call with a float as parameter (example below) ?

I am asking this in order to implement a MISRA rule checker.

Code:
int32_t i = 0;

float32_t float_var;

[...]

for (i = 0; i < float_to_int(float_var); ++i)

{

[...]

}

It seems correct to me since the float is not really use in the controlling expression. But the rules says any objects and that confuse me a little.

Thanks,
Ben

13.5 Loop control expression inconsistencies

Wed, 30 May 2012 10:19:09 +0000

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:

Quote:...
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]
bool Test_Index(int32_t index, int32_t bound){
return (bool)(p

13.5 for() loops - does simplicity matter?

Tue, 13 Sep 2011 07:51:48 +0000

I have compiled the following code. The compiler accepts the first loop (ending at X) but rejects the other two (ending at X+2 and at X*2)

extern tUI16 X, Y;
void Fn( void )
{
tUI16 i;
for( i = 0u; i < X; i++ ) /* accepted */
{
Y += i;
}
for( i = 0u; i < (X + 2u); i++ ) /* rejected */
{
Y += i;
}
for( i = 0u; i < (X * 2u); i++ ) /* rejected */
{
Y += i;
}
}

The compiler suppliers say the compiler will accept the second expression if it is "a simple test" and that X+2 and X*2 do not pass this test. I feel this is being too restrictive for rule 13.5. Please may I have an opinion on this.

Thanks,

John

Why is the code below cited for violation of MISRA 13.6

Thu, 03 Mar 2011 09:33:52 +0000

Why is the last code line (array element initialization) in the code below being cited for 13.6 violation by Crystal Revs MISRA checker:

Code:
/*Test code for Crystal revs MISRA rule 13.6 */

typedef unsigned char uint8_t

void InitArray(void);

#define LCD_NUM_OF_COLS 2u

#define LCD_NUM_OF_ROWS    10u

uint8_t Test_Array[LCD_NUM_OF_COLS][LCD_NUM_OF_ROWS];

void InitArray(void)

    {

    uint8_t row_index = 0u;

    uint8_t col_index = 0u;    

    for (col_index = 0u; col_index < LCD_NUM_OF_COLS; col_index++)

        {

        for (row_index=0u; row_index < LCD_NUM_OF_ROWS; row_index++)    

            {

            /*    make each element of the array the char NULL    */

            Test_Array[col_index][row_index] = 0u;    

            }    

        }

    }

thanks,
kalpak

Rule 13.3 with respect to 0.0

Tue, 13 Jul 2010 16:58:40 +0000

Does rule 13.3 permit testing a floating point expression against 0.0?

Code:
void f( float flt )

{

if( flt == 0.0 )

    {}

}

If not, how is this test any different than

Code:
void f( float flt )

{

if( !flt )

    {}

}

?

Or does 13.3 not permit the second example either?

Doubt on rule 13.2

Mon, 16 Feb 2009 13:01:24 +0000

One of the examples given for rule 13.2 is:

Code:
if ( y ) /* Not compliant, unless y is effectively Boolean data

                              (e.g. a flag) */

Would it still be not compliant if y is of pointer type?
In case it is compliant, should 13.2 be interpreted as to be applicable only to expressions of integral type?

13.5 clarification on loop index iusage

Thu, 04 Sep 2008 09:23:36 +0000

Dear Misra Committee,

Rule 13.5 seems not clearly explicit about the content of the for expressions.

First expression: Initialization of the loop coounter if present. Can we consider as valid code the following examples:
[code]
int32_t i=0;

for (i++;i

Rule 13.4 clarification

Mon, 01 Sep 2008 15:38:05 +0000

Dear Misra committee,

The rule 13.4 says:
The controlling expression of a for statement shall not contain any objects of floating type.

Does it apply only to loop counter, as suggest in the text explaining the rule ( ... floating-point variables shall not be used for this purpose [loop counter] ...). or to all operand of a controlling expression ?

I mean, can we consider the following for loop as compliant ?

Code:
extern float32_t foo(void);

int32_t i;

float32_t f;

for (i=0; i 1.0 && f < 3.0) ; i++){

  ...

  f = foo()

  ...

}

Thanks, Alexandre.

Infinite loop

Wed, 12 Sep 2007 13:29:11 +0000

What is the preferred implementation of an infinite loop?

Code:
for ( ; ; ) ...

Code:
while (1 == 1) ...

or

something else?

Thanks in advance.

Jonathan

Does 13.7 apply to ALL invariant Boolean expressions?

Tue, 31 Jan 2006 22:12:45 +0000

The example only shows relational operators { < >= }.

What about other operators?
#define OPTION_ONE 0x01
#define OPTION_TWO 0x02

#define MY_OPTIONS (OPTION_ONE)
- or -
#define MY_OPTIONS (OPTION_TWO)
- or -
#define MY_OPTIONS (0x00)
- or -
#define MY_OPTIONS (OPTION_ONE | OPTION_TWO)

if ((MY_OPTIONS & OPTION_ONE) != 0) /* deviation from 13.7? */
{
...
}

In this case, equality operators { == != } are less likely to \"accidentally\" be always true/false (vs. intentionally always true/false), while relational operators can sometimes catch the programmer of guard (due to limited ranges of smaller integer types: [-128 to +127], [0 to +255], etc.

What about sub-expressions?
if ((u8

What is the essential requirement of Rule 13.3 ?

Fri, 09 Sep 2005 13:39:31 +0000

Question: What is the essential requirement of Rule 13.3 ?

Rule 13.3 only prohibits the use of == and !=.

Does this mean that it is legitimate to use the >= and 10.0f ) /* compliant */
â€¦
if ( speed = (10.0f â€“ tolerance)) && ( speed

13.5 for() loops

Fri, 25 Feb 2005 17:02:19 +0000

Hi

Rule 13.5 (required) states: \"The 3 expressions of a for statement shall be concerned only with loop control\", and
\"First expression: initialising the loop counter.
Second expression: shall include testing the loop counter, and optionally other loop control variables.
Third expression: increment or decrement of the loop counter.\"

The implication would appear to be that for() loops should only be used where there is a loop counter. Is that correct, or could you (for example) use a for() loop without a loop counter, in which case there wouldn't be a first expression?

Is the idea to restrict C's for() usage to that of Pascal's ie.

for var := first [ to | downto ] last do ...

? I'm Ok with this, but I feel that either I'm missing something or the rule isn't explicit enough about what for() can and can't be used for.

Regards
John
NEC Technologies (UK)