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