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

Clive Pygott clivepygott at gmail.com
Thu Jul 12 10:34:26 BST 2018


>From my point of view, I'd expect all three example to report a diagnostic
of 'use of uninitialised variable'

The first example is a no-brainer, i cannot get initialised (except by some
exploitation of undefined behaviour - like f writing to some address
derived from the return address, that happens to be the location of i).  Or
was the code intended to be  f(&i); ?  In which case the same argument as
the next two examples apply.

In the second example, if the address of i were assigned to  int *p  (no
extern), then it certainly deserves the diagnostic, as i is still
uninitialised.  With the extern,  if  p  is in the same library as f
(source not visible) and you know from the documentation  that  f  always
assigns a value to the object pointed to by  p, then you in theory still
need the diagnostic but you have an excellent  justification for a
deviation - in MISRA terminology. I say in theory, as I can imagine a way a
tool could be told about properties of f by means of metadata, manually
generated to describe the claimed behaviour of the library routines, so it
might know that  *p  always gets assigned on a call of f. If the source of
the translation unit containing p and f  is available, I'd say it was a
quality of implementation issue whether the diagnostic is raised or not.

Similarly, for the third example, its not undefined behaviour if  f  always
returns a value in the range -1..2 - so like in the second example, I'd
expect the violation to be raised unless there's metadata to describe the
behaviour of f or the code for f is visible - with the possibility of a
justification for a deviation.

    Clive

On Wed, Jul 11, 2018 at 8:22 PM, Martin Sebor <msebor at gmail.com> wrote:

> 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?
>
> Or:
>
>   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.
>
> Martin
>
> _______________________________________________
> C-safe-secure-studygroup mailing list
> C-safe-secure-studygroup at lists.trustable.io
> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-
> secure-studygroup
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20180712/d39293c9/attachment.html>


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