Re: [PATCH] do_multicall and MISRA Rule 8.3\

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.03.2024 14:55, Julien Grall wrote:
> Hi Jan,
> 
> On 15/03/2024 13:24, Jan Beulich wrote:
>> 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?
> 
> I am a bit confused. Reading through the thread you seem to agree that
> the written rules are respected here. So what rules are you talking about?

What was proposed is use of a fixed width type where according to my
reading ./CODING_STYLE says it shouldn't be used.

Jan