On 26/03/2019 15: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).
You are using a little endian specific point of view. That's the only reason the current code would work with a non-fixed width specification. The char[4] variant would work only with a union where the other member would need to be a fixed width type like uint32_t. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
