Re: [PATCH v2.5 3/3] xen/types: Rework stdint vs __{u,s}$N types

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 04/07/2023 3:38 pm, Jan Beulich wrote:
> On 28.06.2023 16:54, Andrew Cooper wrote:
>> Xen uses the stdint types.  Rearrange the types headers to define the
>> compatibility __{u,s}$N types in terms of the stdint types, not the other way
>> around.
>>
>> All supported compilers on architectures other than x86 support the stdint
>> __*_TYPE__ macros.  Move these into a new xen/stdint.h to avoid them being
>> duplicated in each architecture.  For the very old x86 compilers, synthesize
>> suitable types using GCC internals.
>>
>> This cleanup has the side effect of removing all use of the undocumented
>> __signed__ GCC keyword.  This is a vestigial remnant of `gcc -traditional`
>> mode for dialetcs of C prior to the introduction of the signed keyword.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Thanks.

> with one further remark:
>
>> --- /dev/null
>> +++ b/xen/include/xen/stdint.h
>> @@ -0,0 +1,33 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#ifndef __XEN_STDINT_H__
>> +#define __XEN_STDINT_H__
>> +
>> +#ifndef __INT8_TYPE__ /* GCC <= 4.4 */
>> +
>> +/*
>> + * Define the types using GCC internal notation.  Clang understands this 
>> too.
>> + * https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html
>> + */
>> +typedef   signed __attribute__((__mode__(QI)))     int8_t;
>> +typedef unsigned __attribute__((__mode__(QI)))    uint8_t;
>> +typedef   signed __attribute__((__mode__(HI)))    int16_t;
>> +typedef unsigned __attribute__((__mode__(HI)))   uint16_t;
>> +typedef   signed __attribute__((__mode__(SI)))    int32_t;
>> +typedef unsigned __attribute__((__mode__(SI)))   uint32_t;
>> +typedef   signed __attribute__((__mode__(DI)))    int64_t;
>> +typedef unsigned __attribute__((__mode__(DI)))   uint64_t;
> Much like you avoid "mode" potentially being the name of a visible macro,
> the mode identifiers themselves could in principle be, too. Being upper
> case names, perhaps there the risk is even slightly higher. Hence I'd
> prefer if you/we could use __QI__ and alike.

Fixed locally.  I won't resend for just this.

~Andrew