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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.02.2023 19:54, Andrew Cooper wrote:
> On 09/02/2023 10:38 am, 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.
> 
> These types were added in GCC 4.5.  It is 12 years old.  We even use a
> newer C standard than this compiler...

A newer C standard? We're using C99, don't we? And Xen, at this point,
continues to build fine with gcc 4.3. Furthermore I for one didn't
check when Clang gained support for these pre-defs ...

> At this point, it is an unreasonable burden to be continuing to support
> compilers this obsolete, not to mention that the mode attributes are
> unreadable to anyone who isn't a GCC developer and clearly unnecessary
> to begin with.

I disagree about the rant regarding mode attributes, but that's secondary.
What I'm really unhappy about is for this work to grow a dependency on the
long-standing question of what to update our tool chain baseline to. This
has been discussed many times, but there was never a concrete proposal on
a policy that we could use not only now, but also going forward. As it
stands I can't help the impression that this is going to remain unresolved
for an extended period of time. But there not being an appropriate
solution to that other issue shouldn't block the work here. Once that one
is resolved (and provided it's then acceptable also on the Clang side),
we could easily drop the mode attribute fallbacks again.

Jan