Re: [PATCH 1/2] docs/misra: introduce rules.rst

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Jan,

> On 26 May 2022, at 11:15, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 26.05.2022 11:54, Bertrand Marquis wrote:
>> Hi Jan,
>> 
>>> On 26 May 2022, at 10:43, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>> 
>>> On 26.05.2022 03:02, Stefano Stabellini wrote:
>>>> On Wed, 25 May 2022, Julien Grall wrote:
>>>>> On 25/05/2022 01:35, Stefano Stabellini wrote:
>>>>>> +- Rule: Dir 4.7
>>>>>> + - Severity: Required
>>>>>> + - Summary: If a function returns error information then that error
>>>>>> information shall be tested
>>>>>> + - Link:
>>>>>> https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_07.c
>>>>> 
>>>>> 
>>>>> ... this one. We are using (void) + a comment when the return is ignored 
>>>>> on
>>>>> purpose. This is technically not-compliant with MISRA but the best we can 
>>>>> do
>>>>> in some situation.
>>>>> 
>>>>> With your proposed wording, we would technically have to remove them (or 
>>>>> not
>>>>> introduce new one). So I think we need to document that we are allowing
>>>>> deviations so long they are commented.
>>>> 
>>>> Absolutely yes. All of these rules can have deviations as long as they
>>>> make sense and they are commented. Note that we still have to work out
>>>> a good tagging system so that ECLAIR and cppcheck can recognize the
>>>> deviations automatically but for now saying that they need to be
>>>> commented is sufficient I think.
>>>> 
>>>> So I'll add the following on top of the file:
>>>> 
>>>> """
>>>> It is possible that in specific circumstances it is best not to follow a
>>>> rule because it is not possible or because the alternative leads to
>>>> better code quality. Those cases are called "deviations". They are
>>>> permissible as long as they are documented with an in-code comment.
>>>> """
>>> 
>>> Hmm, so you really mean in-code comments. I don't think this will scale
>>> well (see e.g. the DCE related intended deviation), and it also goes
>>> against the "no special casing for every static analysis tool" concern
>>> I did voice on the call.
>> 
>> On this subject the idea was more to define a “xen” way to document
>> deviations in the code and do it in a way so that we could easily substitute
>> the “flag” to adapt it for each analyser using tools or command line options.
> 
> I think the basic scheme of something like this would want laying out
> before doc changes like the one here actually go in, so that it's clear
> what the action is if a new deviation needs adding for whatever reason
> (and also allowing interested people to start contributing patches to
> add respective annotations).

We will work on that but if we wait for everything to be solved we will
never progress.
I have a task on my side (ie at arm) to work on that and Luca Fancellu
will start working on it next month.
Now I do not think that this should block this patch, agreeing on rules does
not mean will respect all of them in the short term so we can wait a bit as I
definitely think that how to document violations in the code and in general
will be a work package on its own and will require some discussion.

Bertrand

> 
> Jan