[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 08/09/2023 16:53, 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?

And perhaps also use min_t instead of min, so that the typecheck can be avoided.

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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.