[C-safe-secure-studygroup] reframing rule 11.6 to focus on undefined behavior

Martin Sebor msebor at gmail.com
Tue Oct 9 00:21:12 BST 2018


On 10/08/2018 04:22 AM, Fulvio Baccaglini wrote:
> On Sat, 2018-10-06 at 11:26 -0600, Martin Sebor wrote:
>> Besides the above, I note that by using the term "cast" the rule
>> excludes implicit conversions from the set of diagnosable cases.
>> For example:
>>
>>    extern void *p;
>>    int i = p;         // compliant (no cast here)
>>    ++i;
>>    p = i;             // undefined yet compliant
>>    i = *(int*)p;      // ditto
>>
>> This is almost certainly unintended and simply the result of
>> sloppy wording, but it needs to be corrected if the rule is
>> to impose meaningful binding requirements on analyzers.
>
> My understanding is that ISO C definitions apply to MISRA C terms,
> unless otherwise specified, and in particular the term "cast" in Rule
> 11.6 "A cast shall not be performed between pointer to void and an
> arithmetic type" is intended, because:
>
> (1) both 'int i = p;' and 'p = i;' are constraint violations, and
> therefore already captured by Rule 1.1

Unfortunately, there is no constraint in C that pointers cannot
be implicitly converted to integers or vice versa.  In fact, C
is explicit in 6.3.2.3 that:

   -5-  An integer may be converted to any pointer type. ...
   -6-  Any pointer type may be converted to an integer type. ...

The result in both cases is implementation-defined and using
it may be undefined.

>
> (2) 'i = *(int*)p;' is already captured by Rule 11.5 "A conversion
> should not be performed from pointer to void into pointer to object"

The point of the example above is to illustrate that rule 11.6
is formulated in a way that make its needlessly permissive as
a result of considering the assignment 'p = i' compliant even
tough it's strictly undefined oin and of itself, and even in
the presence of the subsequent access in 'i = *(int*)p').

The point of the rest of my email besides providing the example
reformulation of the rule I was asked for on our call is to show
that 11.6 is also unnecessarily restrictive (e.g., it considers
the well-defined conversion between pointers and intptr_t
non-compliant, among other things.)

The effect of such rules is that they generate noise that not
only doesn't contribute to code improvements, but that is often
harmful as programmers invent workarounds or kludges to silence
false positives.  This leads to obfuscated code that's difficult
for both tools and humans to understand, and that is even more
likely to contain bugs than the straightforward code the tool
so senselessly complained about.

Martin




More information about the C-safe-secure-studygroup mailing list