[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