Re: [PATCH v2] docs/misra: document the expected sizes of integer types

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.03.2024 01:07, Stefano Stabellini wrote:
> On Fri, 15 Mar 2024, Jan Beulich wrote:
>> On 14.03.2024 23:17, Stefano Stabellini wrote:
>>> Xen makes assumptions about the size of integer types on the various
>>> architectures. Document these assumptions.
>>
>> My prior reservation wrt exact vs minimum sizes remains.
> 
> We have to specify the exact size. In practice the size is predetermined
> and exact with all our supported compilers given a architecture.

But that's not the purpose of this document; if it was down to what
compilers offer, we could refer to compiler documentation (and iirc we
already do for various aspects). The purpose of this document, aiui,
is to document assumption we make in hypervisor code. And those should
be >=, not ==.

> Most importantly, unfortunately we use non-fixed-size integer types in
> C hypercall entry points and public ABIs. In my opinion, that is not
> acceptable.

The problem is that I can't see the reason for you thinking so. The C
entry points sit past assembly code doing (required to do) necessary
adjustments, if any. If there was no assembly layer, whether to use
fixed with types for such parameters would depend on what the
architecture guarantees.

As to public ABIs - that's structure definitions, and I agree we ought
to uniformly use fixed-width types there. We largely do; a few things
still require fixing.

> We have two options:
> 
> 1) we go with this document, and we clarify that even if we specify
>   "unsigned int", we actually mean a 32-bit integer
> 
> 2) we change all our public ABIs and C hypercall entry points to use
>    fixed-size types (e.g. s/unsigned int/uint32_t/g)
> 
> 2) is preferred because it is clearer but it is more work. So I went
> with 1). I also thought you would like 1) more.

For ABIs (i.e. structures) we ought to be making that change anyway.
Leaving basic types in there is latently buggy.

I'm happy to see a document like this added, for the purpose described
above. But to me 1) and 2) and largely independent of one another.

Jan