Re: [PATCH 2/6] common: move standard C fixed width type declarations to common header

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

On 2/9/23 05:38, Jan Beulich wrote:
> Have these in one place, for all architectures to use. Also use the C99
> types as the "original" ones, and derive the Linux compatible ones
> (which we're trying to phase out). For __s<N>, seeing that no uses exist
> anymore, move them to a new Linux compatibility header (as an act of
> precaution - we don't have any uses of these types right now).
>
> Modern compilers supply __{,U}INT<n>_TYPE__ - use those if available.
> Otherwise fall back to using "mode" attributes, but this can be relied
> upon only when bytes are 8 bits wide. Should there ever be a port to an
> architecture not matching this, it would need to define the fixed width
> types locally by some other means.
>
> In a few cases inclusion of asm/types.h needs replacing by xen/types.h.
> Further in common/trace.c take the opportunity and also drop the
> apparently unused inclusion of asm/io.h at the same time. Finally in
> some Flask sources inclusion of asm/byteorder.h needs moving later.
>
> No functional change intended.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> RFC: I know Andrew would prefer these types to move to a new
>       xen/stdint.h, but not being fully convinced of this myself, I was
>       hoping for others to voice views.
IHHO since there is already stdarg.h and stdbool.h, which establishes 
some degree of following C standard library includes, it would seem more 
logical to move to stdint.h. The main point here is not whether 
following the C standard library includes is the right approach, but 
that consistency is more important. Having a mixture of types.h and C 
standard library includes leaves one having to keep track of which C 
standard library includes are present versus what is in type.h.