[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

As a side note, Xen will use LP64, hence why we tend to use 'unsigned long' to describe 32-bit for Arm32 and 64-bit for Arm64.

Cheers,

--
Julien Grall



 


Rackspace

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