Re: [XEN PATCH] automaton/eclair: add deviations for MISRA C:2012 Rule 13.6

[Federico Serafini <federico.serafini@xxxxxxxxxxx>]

On 04/04/24 16:34, Jan Beulich wrote:
> On 04.04.2024 16:21, Federico Serafini wrote:
> > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > @@ -333,6 +333,14 @@ of the short-circuit evaluation strategy of such logical 
> > operators."
> >   -config=MC3R1.R13.5,reports+={disapplied,"any()"}
> >   -doc_end
> >   
> > +-doc_begin="Macros alternative_vcall[0-9] use sizeof to type-check \"func\" and the func parameters without evaluating them."
> > +-config=MC3R1.R13.6,reports+={deliberate,"any_area(any_loc(any_exp(macro(^alternative_vcall[0-9]$))))"}
> > +-doc_end
> alternative_vcall(), for now at least, is x86-only. Why blindly deviate it also
> for Arm?
I'll reduce the scope to x86 only.

> > +-doc_begin="Macro chk_fld is only used to introduce BUILD_BUG_ON checks in very 
> > specific cases where by code inspection you can see that its usage is correct. The 
> > BUILD_BUG_ON checks check that EFI_TIME and struct xenpf_efi_time fields match."
> > +-config=MC3R1.R13.6,reports+={deliberate,"any_area(any_loc(any_exp(macro(^chk_fld$))))"}
> > +-doc_end
> As indicated on earlier occasions - when a macro isn't global, its deviation
> better wouldn't be global either. An identically named macro may be introduced
> elsewhere, and may not need deviating there.
Noted.

> > --- a/docs/misra/deviations.rst
> > +++ b/docs/misra/deviations.rst
> > @@ -279,6 +279,18 @@ Deviations related to MISRA C:2012 Rules:
> >          the short-circuit evaluation strategy for logical operators.
> >        - Project-wide deviation; tagged as `disapplied` for ECLAIR.
> >   
> > +   * - R13.6
> > +     - Macros alternative_vcall[0-9] use sizeof to type-check \"func\" and the
> > +       func parameters without evaluating them.
> Just to mention it: The return type of the function isn't really of interest
> there. What's being checked is that the argument types match the corresponding
> parameter ones, which otherwise would "naturally" be done by the compiler when
> seeing function calls. Might be useful to state no more and no less than what
> is really needed.
Noted.

--
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)