[C-safe-secure-studygroup] what constitutes a rule violation?

Martin Sebor msebor at gmail.com
Wed Jul 11 20:22:32 BST 2018

I get the impression that we're spending large amounts of time
with little progress by rehashing the same issue because we're
not on the same page about a fundamental question: what
constitutes a rule violation.

Take the following examples.  Assume what you see is the complete
program that's visible to the analyzer; what's not defined in it
is in some library that the analyzer doesn't see or have knowledge
of -- like in the vast majority of software.

   extern int f (int*);

   int main (void)
     int i;   // uninitialized
     f (&);
     return i;

Is it anyone's expectation that the read of i in main violate
MISRA Rule 9.1 or TS 17961 rule 5.35 (reading uninitialized
memory), and so requires a diagnostic?

What about if I change main to

   int main (void)
     int i;
     extern int *p = &i;
     f (0);
     return i;

Does this require a diagnostic?  Should it?


   int main (void)
     int i;
     switch (f (0)) {
     case 0:
     case 1:
     case 2: i = 0; break;
     case -1: i = 1; break;
     return i;

Does this require a diagnostic?

What do the analyzers that implement this rule do?  Does
it change from rule to rule?  Should it be allowed to?

I don't believe we can make forward progress unless we are
clear on what the answers are or what we want them to be.
I don't think the spec will have value to users unless it
makes it clear for each rule what constitutes a violation
and whether it's considered a certain violation or just
a possible one.


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