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

From: Jan Beulich <jbeulich@suse.com>
To: Julien Grall <julien@xen.org>
Cc: andrew.cooper3@citrix.com, bertrand.marquis@arm.com,
	george.dunlap@citrix.com, michal.orzel@amd.com,
	roger.pau@citrix.com, xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2] docs/misra: document the expected sizes of integer types
Date: Mon, 25 Mar 2024 12:16:44 +0100	[thread overview]
Message-ID: <b6430745-2b1a-43e7-9f11-88c8c8f04b4a@suse.com> (raw)
In-Reply-To: <a5c01d46-eb46-49d1-8ffd-98b6d1680daa@xen.org>

On 22.03.2024 00:17, 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.

"... is 64-bit" you mean?

Jan

> 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,
>