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. Bertrand > > Jan
