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

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

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?
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)