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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 21 Mar 2024, Julien Grall wrote:
> Hi Stefano,
> 
> I haven't fully read the thread. But I wanted to clarify something.
> 
> On 21/03/2024 19:03, Stefano Stabellini wrote:
> > > > Or possibly unsigned long depending on the parameter.
> > > 
> > > You're contradicting yourself: You mean to advocate for fixed-width types,
> > > yet then you suggest "unsigned long".
> > 
> > No. I explained it in another thread a couple of days ago. There are
> > cases where we have fixed-width types but the type changes by
> > architecture: 32-bit for 32-bit archs and 64-bit for 64-bit archs.
> > Rather than having #ifdefs, which is also an option, that is the one
> > case where using "unsigned long" could be a decent compromise. In this
> > context "unsigned long" means register size (on ARM we even have
> > register_t). Once you pick an architecture, the size is actually meant
> > to be fixed. In fact, it is specified in this document. Which is one of
> > the reasons why we have to use == in this document and not >=. In
> > general, fixed-width types like uint32_t are better because they are
> > clearer and unambiguous. When possible I think they should be our first
> > choice in ABIs.
> 
> "unsigned long" is not fixed in a given architecture. It will change base on
> the data model used by the OS. For instance, for Arm 64-bit, we have 3 models:
> ILP32, LP64, LLP64. Only on LP64, 'unsigned long' is 32-bit.
> 
> So effectively unsigned long can't be used in the ABI.

If someone sees "unsigned long" in the public headers to define a public
Xen ABI, they would need to refer to this document to understand what
"unsigned long" really means, which specifies size and alignment of
"unsigned long" based on the architecture. In other words, this document
mandates LP64 (at least for safety configuration, given that nothing
else is tested).

This is the reason why ideally we wouldn't have any "unsigned long" in
the Xen ABI at all. They are not as clear as explicitly-sized integers
(e.g. uint32_t). In an ideal world, we would use explicitly-sized
integers for everything in public ABIs.