Re: [PATCH] do_multicall and MISRA Rule 8.3\

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.03.2024 13:17, George Dunlap wrote:
> On Fri, Mar 15, 2024 at 11:57 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>> It sounds like Andy and Stefano feel like this is a situation where "a
>>> fixed width quantity is meant"; absent any further guidance from the
>>> CODING_STYLE about when fixed widths should or should not be used, I
>>> don't think this change would be a violation of CODING_STYLE.
>>
>> As with any not sufficiently clear statement, that's certainly true here,
>> too. Yet if we try to give as wide meaning as possible to "a fixed width
>> quantity is meant", there's basically no restriction on use of fixed width
>> types because everyone can just say "but I mean a fixed width quantity
>> here". I think the earlier sentence needs taking with higher priority,
>> i.e. if a basic type does for the purpose, that's what should be used. The
>> 2nd sentence then only tries to further clarify what the 1st means.
> 
> Come, now.  There are lots of situations where we just need some sort
> of number, and there's no real need to worry about the exact size.
> There are other situations, where we mean "whatever covers the whole
> address space" or the like, where it makes sense to have something
> like "unsigned long", which changes size, but in predictable and
> useful ways.  There are other situations, like when talking over an
> API to code which may be compiled by a different compiler, or may be
> running in a different processor mode, where we want to be more
> specific, and set an exact number of bits.
> 
> Should we use uint32_t for random loop variables?  Pretty clearly
> "No".  Should we use uint32_t for the C entry of a hypercall, even
> though the assembly code allegedly makes that unnecessary?  At least
> two core maintainers think "maybe just to be safe".  That's hardly a
> slippery slope of "anyone can say anything".
> 
> Other than "it's in CODING_STYLE", and "it's not really necessary
> because it's ensured in the assembly code", you haven't advanced a
> single reason why "uint32_t" is problematic.

And it isn't, I never said it would be. But if we set rules for
ourselves, why would we take the first opportunity to not respect them?

Jan