On 26/03/2019 14:39, Jan Beulich wrote: >>>> On 26.03.19 at 15:23, <jgr...@suse.com> wrote: >> IMO especially in the CPUID case it is desirable to explicitly specify >> the width of the data. Looking at nodes 0x80000002 and following this >> should be rather clear (and I even think get_model_name() should be >> modified to use a pointer to uint32_t instead of unsigned int). Using >> a type with size >= 4 doesn't fit really well. You want size == 4. > Why? Fixed width types only introduce unnecessary restrictions > when wanting to re-use code in other environments. And I don't > see why CPUID nodes 0x8000000[234] would be any better (or > worse) as an example here. If anything they tell us that neither > uint32_t nor unsigned int are right, and it should be char[4] or > uint8_t[4] instead (depending on whether we want to tie > ourselves to CHAR_BIT == 8, which clearly is more restrictive > than sizeof(int) >= 4, but otoh is also less likely to get in the > way).
The ABI of CPUID really is 2x uint32_t input, 4x uint32_t output. It is only by current convention that the data is also valid ASCII, and there is absolutely nothing which prevents a new vendor choosing to put non-ASCII content in their id string. Given the recent developments from China, I'm slightly surprised that we haven't seen any UTF-8 (or UTF-16 for that matter) yet. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
