MISRA Discussion Forums - Rule 12.6 and functions taking/returning Boolean values.

The second part of Rule 12.6 says that:
"Expressions that are effectively Boolean should not be used as operands to operators other than ..."
The list of the allowed operators has been corrected in TC1 to include &&, ||, !, =, ==, != and ?:

What about the function call operator () ?

If a Boolean value (by enforcement or by construction) is used as an argument to a function having a parameter whose type is Boolean (by enforcement), are we violating Rule 12.6? For instance:

Code:
typedef /* Boolean-by-enforcement type */ bool_t;

void foo(bool_t b);

void bar(int32_t a, int32_t b) {

  bool_t b = (a == b);

  foo(b); /* Non-compliant? */

}

A similar conversion problem exists when returning a Boolean value. In this case Rule 12.6 never applies (even though a Boolean value is being "abused") merely because, strictly speaking, the return statement is not an operator. For instance:

Code:
int32_t bar(int32_t a, int32_t b) {

  bool_t b = (a == b);

  return b; /* Compliant? */

}

Are the two examples above matching what was really meant by Rule 12.6 and TC1?

The function call operator should have been included in this list with the caveat that expressions with effectively Boolean type may be used in the argument list where the corresponding parameter also has effectively Boolean type.

An expression with effectively Boolean type may also be used in a return statement and also to initialise an object but Rule 12.6 does not apply to these cases because there are no operators present.

misra-c Wrote:The function call operator should have been included in this list with the caveat that expressions with effectively Boolean type may be used in the argument list where the corresponding parameter also has effectively Boolean type.

OK, so the first example is compliant with respect to the proper meaning of Rule 12.6.

misra-c Wrote:An expression with effectively Boolean type may also be used in a return statement and also to initialise an object but Rule 12.6 does not apply to these cases because there are no operators present.

If Rule 12.6 does not apply to return statements (and object inizializations), then which rule is violated by the code in the second example above?
As far as we can tell, the overall guideline is that effectively Boolean types/expressions should not be confused with the proper arithmetic types/expressions, i.e., they need to be clearly separated as is the case for "plain char" types/expressions. However, we seem to be missing a specific rule corresponding to Rule 6.1.

zaffanella Wrote:If Rule 12.6 does not apply to return statements (and object inizializations), then which rule is violated by the code in the second example above?
As far as we can tell, the overall guideline is that effectively Boolean types/expressions should not be confused with the proper arithmetic types/expressions, i.e., they need to be clearly separated as is the case for "plain char" types/expressions. However, we seem to be missing a specific rule corresponding to Rule 6.1.

There is no rule for effectively Boolean types corresponding to Rule 6.1 although it would clearly be sensible to write code as if such a rule did exist.

The subject of types and expressions will be given much more thorough treatment in the next version of the MISRA C Guidelines. This version, commonly referred to as MISRA C3 is currently undergoing public review in readiness for release later this year.