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

[Jan Beulich <jbeulich@xxxxxxxx>]

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).

Jan