Re: [XEN PATCH] xen/types: address Rule 10.1 for macro BITS_TO_LONGS

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 8 Sep 2023, Nicola Vetrini wrote:
> On 08/09/2023 13:59, Jan Beulich wrote:
> > On 08.09.2023 13:57, Jan Beulich wrote:
> > > On 08.09.2023 10:48, Nicola Vetrini wrote:
> > > > There is a build error due to -Werror because of a pointer comparison at
> > > > line 469 of common/numa.c:
> > > > i = min(PADDR_BITS, BITS_PER_LONG - 1);
> > > > where
> > > > #define PADDR_BITS              52
> > > > 
> > > > I guess PADDR_BITS can become unsigned or gain a cast
> > > 
> > > While generally converting constants to unsigned comes with a certain
> > > risk, I think for this (and its siblings) this ought to be okay. As to
> > > the alternative of a cast - before considering that, please consider
> > > e.g. adding 0u (as we do elsewhere in the code base to deal with such
> > > cases).
> > 
> > And just after sending I realized that this would still be disliked by
> > Misra's type system. (Much like then aiui the 1 above will need to
> > become 1u. Which is all pretty horrible.)
> > 
> > Jan
> 
> I have a proposal: in our tests we enabled an ECLAIR configuration that allows
> to bypass the
> constraint imposed by Rule 10.4 that warrants the 1U iff the value is constant
> and both types
> can represent it correctly (in this case BITS_PER_LONG -1). This would allow
> using the proposed
> solution and documenting why it's ok not to respect R10.4. What do you think?

I think that would be OK. I think we would want to document this in
rules.rst. Please send a patch.