[C-safe-secure-studygroup] Tentative analysis of MISRA C:2012 Rule 11.7 for TS-17961 purposes

[Fulvio Baccaglini]

Hi,

Here is my understanding of a couple of points raised about Rule 11.7 during the teleconference of 28th Nov, and the provisional conclusions reached.

Rule 11.7 "A cast shall not be performed between pointer to object and a non-integer arithmetic type"

(1) Should the part of Rule 11.7 that applies to casts from/to essentially floating still be included? Being these casts a constraint violation as of C11, should there still be a dedicated rule to specifically prevent them?

This is currently deemed not to be necessary.

MISRA C:2012 includes a general Rule 1.3 about preventing undefined and critical unspecified behaviour, whose amplification states: "Some undefined and unspecified behaviours are dealt with by specific rules. This rule prevents all other undefined and critical unspecified behaviours."

There is however no equivalent statement for general Rule 1.1, which applies to constraint violations.

(2) What about conversion from pointer to bool?

Rule 11.7 only applies to casts while Rule 11.4 also applies to implicit conversions. For implicit conversions, an exception may be considered for:

~~~~~~~~>
extern int * x;

if (x)
{
  // ...
}
<~~~~~~~~

As this would be well defined:

[C18-6.8.4.1-2] The if statement: "... the first substatement is executed if the expression compares unequal to 0. In the else form, the second substatement is executed if the expression compares equal to 0 ..."

[C18-6.3.2.3-3] Pointers - "An integer constant expression with the value 0, or such an expression cast to type void * , is called a null pointer constant."

[C18-6.5.9-5] Equality operators - "If one operand is a pointer and the other is a null pointer constant, the null pointer constant is converted to the type of the pointer."

[C18-6.5.9-5] Equality operators - "Two pointers compare equal if and only if both are null pointers ..."

But what happens if a cast is introduced?

~~~~~~~~>
if ((bool) x)
{
  // ...
}
<~~~~~~~~

[C18-6.2.5] Types: "An object declared as type _Bool is large enough to store the values 0 and 1."

[C18-6.2.5] Types - "The type _Bool ... unsigned integer types"

[C18-6.3.2.3] Pointers: "Any pointer type may be converted to an integer type. Except as previously specified, the result is implementation-defined. If the result cannot be represented in the integer type, the behavior is undefined. The result need not be in the range of values of any integer type."

This suggests undefined behaviour, even if the subsequent implicit comparison with 0 is safe:

[C18-6.5.9-5] Equality operators - "If both of the operands have arithmetic type, the usual arithmetic conversions are performed."

The current consensus is to drop Rule 11.7, and if an exception for _Bool is made, then it is to be made to Rule 11.4 and it is to be limited to implicit conversions.

Fulvio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20181211/55b6704b/attachment-0001.html>