Hi Jan, > On 26 May 2022, at 11:15, Jan Beulich <jbeul...@suse.com> wrote: > > On 26.05.2022 11:54, Bertrand Marquis wrote: >> Hi Jan, >> >>> On 26 May 2022, at 10:43, Jan Beulich <jbeul...@suse.com> 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
