Re: [XEN PATCH][for-next][for-4.19 v2 1/8] xen/include: add macro LOWEST_BIT

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 16/10/2023 18:30, Jan Beulich wrote:
> On 16.10.2023 18:17, Nicola Vetrini wrote:
> > On 16/10/2023 17:33, Jan Beulich wrote:
> > > On 12.10.2023 17:28, Nicola Vetrini wrote:
> > > > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > > @@ -274,6 +274,12 @@ still non-negative."
> > > >  -config=MC3R1.R10.1,etypes+={safe,
> > > > "stmt(operator(logical)||node(conditional_operator||binary_conditional_operator))",
> > > > "dst_type(ebool||boolean)"}
> > > >  -doc_end
> > > >
> > > > +-doc_begin="The macro LOWEST_BIT encapsulates a well-known pattern 
> > > > to
> > > > obtain the value
> > > > +2^ffs(x) for unsigned integers on two's complement architectures
> > > > +(all the architectures supported by Xen satisfy this requirement)."
> > > > +-config=MC3R1.R10.1,reports+={safe,
> > > > "any_area(any_loc(any_exp(macro(^LOWEST_BIT$))))"}
> > > > +-doc_end
> > > Why is this added here rather than by ...
> > >
> > > > --- a/xen/include/xen/macros.h
> > > > +++ b/xen/include/xen/macros.h
> > > > @@ -8,8 +8,10 @@
> > > >  #define DIV_ROUND(n, d) (((n) + (d) / 2) / (d))
> > > >  #define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
> > > >
> > > > -#define MASK_EXTR(v, m) (((v) & (m)) / ((m) & -(m)))
> > > > -#define MASK_INSR(v, m) (((v) * ((m) & -(m))) & (m))
> > > a SAF-<n>-safe comment here?
> > One reason is that now that violations only belonging to tool
> > configurations
> > and similar are documented in docs/misra/deviations.rst (committed in
> > Stefano's
> > branch for-4.19 [1]).
> But tool configuration means every analysis tool needs configuring
> separately. That's why the comment tagging scheme was decided to be
> preferred, iirc.
>
> > Also, there were disagreements on the SAF naming
> > scheme, and
> > patches like those would not be accepted at the moment.
> Well, that needs resolving. The naming there shouldn't lead to patches
> being accepted that later may need redoing.
>
> Jan
While this is true, in this case I'm not willing to deviate with a SAF, 
given that
some ECLAIR-specific configuration would be needed anyways, given that 
I'm deviating a macro definition, rather than the line where it's 
actually used (and maybe other tools would need
that as well).

--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)