[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN PATCH] xen/types: address Rule 10.1 for macro BITS_TO_LONGS
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.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |