Re: deviations tagging

[Luca Fancellu <Luca.Fancellu@xxxxxxx>]

> On 15 Jun 2022, at 07:03, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 15.06.2022 00:47, Stefano Stabellini wrote:
>> Roberto was suggesting to use the following different categories for
>> tagging deviations. We could pick any "TAG" we like for the in-code
>> comments (or other tagging systems).
>> 
>> I am also CCing the MISRA C team to give them early visibility on this.
>> Feel free to provide early feedback if you have any. The plan is to
>> discuss it further during the next fusa-sig call and come up with a more
>> detailed proposal (including the actual tags, how to use them and more)
>> for xen-devel next.
> 
> And as early feedback: They all look like they're meant to be used
> together with some rule reference (or else there's insufficient context
> to know what is being talked about). Yet iirc we said we'd want tool-
> agnostic tags, such that the same kind of comments can also be used to
> mark e.g. things Coverity has found and we have decided to leave alone.
> 
> Jan
> 
>> adopted
>> 
>>   The report should be considered originated by adopted code without any
>>   contribution of native code to the report.
>> 
>> safe
>> 
>>   The report is correct but the specific behavior is safe under every
>>   aspect assumed to be covered by the guideline.
>> 
>> relied
>> 
>>   The report is correct but the rule concerns exclusively "developer
>>   confusion" or readability matters that are not relevant for adopted code,
>>   which is assumed to work as is and it is not meant to be read, reviewed
>>   or modified by human programmers.  To be used for adopted code only.
>> 
>> false-positive
>> 
>>   In the opinion of the developer the violation report is not correct
>>   and the problem has been notified to the tool provider.
>>   To be used only for violation reports.
>> 
>> compliant
>> 
>>   The developer can prove that the possible non-compliance shown by
>>   caution report cannot happen in any situation and can motivate such
>>   claim.  To be used only for caution reports.
>> 
>> false-negative
>> 
>>   The developer has found a non-compliance not shown by the tool and the
>>   problem has been notified to the tool provider.
>> 
> 

Hi all,

Indeed, they all look very useful and very helpful, this month one of my task 
is to
explore how some of the tool works in the context of in-code comments for 
violation
suppression, using cppcheck, Coverity and Eclair.
I’ve found some documentation for cppcheck and Coverity on how to suppress the
checker, I’m missing Eclair, but I’m confident that Roberto can help us on that.

As first thought I was thinking to propose the above tags with an incremental 
number
that could work as a link to a file containing the justification for each 
finding.

/* Safe-<number> */

So that a preprocessor script can be used later to substitute the tag with the 
appropriate
in-code comment suppression tag for a specified checker tool.

I will also propose to you a template for the justification so that we can 
start from there
and discuss on it.

Cheers,
Luca