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

[Martin Sebor]

On 07/12/2018 11:51 AM, Fulvio Baccaglini wrote:
> On Thu, 2018-07-12 at 10:55 -0600, Martin Sebor wrote:
>> Does MISRA really expect a diagnostic here if the analyzer
>> doesn't know what the definition of f() looks like?  Are
>> engineers coding to MISRA really expected and willing to accept
>> such diagnostics and put effort into going through the deviation
>> process for each instance of what is a pervasive idiom?
>
> MISRA C:2012 section 6.1 says "a rule is a guideline for which a
> complete description of the requirement has been provided". This
> includes providing the required source code. So I would argue that if
> this information is not provided, then the question "does this example
> violate Rule 9.1" cannot be answered.

The writer of an analyzer that conforms to the spec has no choice
but to answer the question, for at least two reasons:

1) it doesn't always have access to the source of the whole program
2) even with access to the source code of the entire program it may
    not be able to determine in finite time whether or not a rule has
    in fact been violated

For many undecidable rules these cases are the overwhelming majority
of potential violations.  The rest are trivial and often caught by
testing or visual inspection even before the analyzer has a chance
to rum.

Similarly, a company that's chosen MISRA as their coding standard
has no choice but to answer the question whether it's a true or
false positive when the analyzer they use issues a diagnostic.
They need to know if they need to fix a bug or whether to create
a deviation.

As Clive likes to point out, if it comes to litigation, someone
will go through the deviation document and ask questions about
it, so the company had better have an answer (preferably
the right one).

> IMO from a MISRA perspective,
> when information is missing, the question is not how a tool can/should
> enforce rules, but how a tool can/should assist the user in complying
> with directives.

Agreed.  This is one an area where I think we can drive advances
in the state of the art, such as by specifying annotations.

Martin