[PATCH v2] xen: Use auto as per C23

[PATCH v2] xen: Use auto as per C23

[Andrew Cooper]

In macros it is common to declare local variables using typeof(param) in order
to ensure that side effects are only evaluated once.  A consequence of this is
double textural expansion of the parameter, which can get out of hand very
quickly with nested macros.

In C23, the auto keyword has been repurposed to perform type inference.

A GCC extension, __auto_type, is now avaialble in the new toolchain baseline
and avoids the double textural expansion.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Roberto Bagnara <roberto.bagnara@bugseng.com>
CC: Nicola Vetrini <nicola.vetrini@bugseng.com>
CC: consulting@bugseng.com <consulting@bugseng.com>

The resulting build is identical.

v2:
 * Use auto directly
 * Eclair configuration

https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1985289434
---
 automation/eclair_analysis/ECLAIR/toolchain.ecl | 11 +++++++++--
 docs/misra/C-language-toolchain.rst             |  2 ++
 xen/include/xen/compiler.h                      | 14 ++++++++++++++
 xen/include/xen/macros.h                        | 14 +++++++-------
 4 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/toolchain.ecl b/automation/eclair_analysis/ECLAIR/toolchain.ecl
index 842f8377e561..125f99a06583 100644
--- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
+++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
@@ -15,6 +15,7 @@
     __alignof__, __alignof: see Sections \"6.48 Alternate Keywords\" and \"6.44 Determining the Alignment of Functions, Types or Variables\" of "GCC_MANUAL".
     asm, __asm__: see Sections \"6.48 Alternate Keywords\" and \"6.47 How to Use Inline Assembly Language in C Code\" of "GCC_MANUAL".
     __attribute__: see Section \"6.39 Attribute Syntax\" of "GCC_MANUAL".
+    __auto_type: see Section \"6.7 Referring to a Type with typeof\" of "GCC_MANUAL".
     __builtin_offsetof: see Section \"6.53 Support for offsetof\" of "GCC_MANUAL".
     __builtin_types_compatible_p: see Section \"6.59 Other Built-in Functions Provided by GCC\" of "GCC_MANUAL".
     __builtin_va_arg: non-documented GCC extension.
@@ -26,6 +27,7 @@
 -name_selector+={alignof, "^(__alignof__|__alignof)$"}
 -name_selector+={asm, "^(__asm__|asm)$"}
 -name_selector+={attribute, "^__attribute__$"}
+-name_selector+={auto_type, "^__auto_type$"}
 -name_selector+={builtin_offsetof, "^__builtin_offsetof$"}
 -name_selector+={builtin_types_p, "^__builtin_types_compatible_p$"}
 -name_selector+={builtin_va_arg, "^__builtin_va_arg$"}
@@ -39,6 +41,7 @@
 "alignof||
 asm||
 attribute||
+auto_type||
 builtin_offsetof||
 builtin_types_p||
 builtin_va_arg||
@@ -114,6 +117,7 @@ volatile"
 -doc_end
 
 -doc_begin="
+    ext_auto_type: see Section \"6.7 Referring to a Type with typeof\" of "GCC_MANUAL".
     ext_c_missing_varargs_arg: see Section \"6.21 Macros with a Variable Number of Arguments\" of "GCC_MANUAL".
     ext_enum_value_not_int: non-documented GCC extension.
     ext_flexible_array_in_array: see Section \"6.18 Arrays of Length Zero\" of "GCC_MANUAL".
@@ -126,6 +130,7 @@ volatile"
     ext_return_has_void_expr: see the documentation for -Wreturn-type in Section \"3.8 Options to Request or Suppress Warnings\" of "GCC_MANUAL".
     ext_sizeof_alignof_void_type: see Section \"6.24 Arithmetic on void- and Function-Pointers\" of "GCC_MANUAL".
 "
+-name_selector+={ext_auto_type, "^ext_auto_type$"}
 -name_selector+={ext_c_missing_varargs_arg, "^ext_c_missing_varargs_arg$"}
 -name_selector+={ext_enum_value_not_int, "^ext_enum_value_not_int$"}
 -name_selector+={ext_flexible_array_in_array, "^ext_flexible_array_in_array$"}
@@ -139,7 +144,8 @@ volatile"
 -name_selector+={ext_sizeof_alignof_void_type, "^ext_sizeof_alignof_void_type$"}
 
 -config=STD.diag,behavior+={c99,GCC_ARM64,
-"ext_c_missing_varargs_arg||
+"ext_auto_type||
+ext_c_missing_varargs_arg||
 ext_forward_ref_enum_def||
 ext_gnu_array_range||
 ext_gnu_statement_expr_macro||
@@ -149,7 +155,8 @@ ext_return_has_void_expr||
 ext_sizeof_alignof_void_type"
 }
 -config=STD.diag,behavior+={c99,GCC_X86_64,
-"ext_c_missing_varargs_arg||
+"ext_auto_type||
+ext_c_missing_varargs_arg||
 ext_enum_value_not_int||
 ext_flexible_array_in_array||
 ext_flexible_array_in_struct||
diff --git a/docs/misra/C-language-toolchain.rst b/docs/misra/C-language-toolchain.rst
index cb81f5c09872..635936004554 100644
--- a/docs/misra/C-language-toolchain.rst
+++ b/docs/misra/C-language-toolchain.rst
@@ -94,6 +94,8 @@ The table columns are as follows:
           see Sections "6.48 Alternate Keywords" and "6.44 Determining the Alignment of Functions, Types or Variables" of GCC_MANUAL.
        __attribute__:
           see Section "6.39 Attribute Syntax" of GCC_MANUAL.
+       __auto_type:
+          see Section "6.7 Referring to a Type with typeof" of GCC_MANUAL.
        __builtin_types_compatible_p:
           see Section "6.59 Other Built-in Functions Provided by GCC" of GCC_MANUAL.
        __builtin_va_arg:
diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index 88bf26bc5109..38ef5d82ad95 100644
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -64,6 +64,20 @@
 # define asm_inline asm
 #endif
 
+/*
+ * In C23, the auto keyword has been repurposed to perform type inference.
+ *
+ * This behaviour is available via the __auto_type extension in supported
+ * toolchains.
+ *
+ * https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Auto-Type.html
+ * https://clang.llvm.org/docs/LanguageExtensions.html#auto-type
+ */
+#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L
+/* SAF-3-safe MISRA C Rule 20.4: Giving the keyword it's C23 meaning. */
+#define auto __auto_type
+#endif
+
 /*
  * Add the pseudo keyword 'fallthrough' so case statement blocks
  * must end with any of these keywords:
diff --git a/xen/include/xen/macros.h b/xen/include/xen/macros.h
index f9ccde86fb23..ceca2e4a1bf1 100644
--- a/xen/include/xen/macros.h
+++ b/xen/include/xen/macros.h
@@ -63,18 +63,18 @@
 /* Hide a value from the optimiser. */
 #define HIDE(x)                                 \
     ({                                          \
-        typeof(x) _x = (x);                     \
+        auto _x = (x);                          \
         asm volatile ( "" : "+r" (_x) );        \
         _x;                                     \
     })
 
 #define ABS(x) ({                              \
-    typeof(x) x_ = (x);                        \
+    auto x_ = (x);                             \
     (x_ < 0) ? -x_ : x_;                       \
 })
 
 #define SWAP(a, b) \
-   do { typeof(a) t_ = (a); (a) = (b); (b) = t_; } while ( 0 )
+   do { auto t_ = (a); (a) = (b); (b) = t_; } while ( 0 )
 
 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]) + __must_be_array(x))
 
@@ -102,15 +102,15 @@
  */
 #define min(x, y)                               \
     ({                                          \
-        const typeof(x) _x = (x);               \
-        const typeof(y) _y = (y);               \
+        const auto _x = (x);                    \
+        const auto _y = (y);                    \
         (void)(&_x == &_y); /* typecheck */     \
         _x < _y ? _x : _y;                      \
     })
 #define max(x, y)                               \
     ({                                          \
-        const typeof(x) _x = (x);               \
-        const typeof(y) _y = (y);               \
+        const auto _x = (x);                    \
+        const auto _y = (y);                    \
         (void)(&_x == &_y); /* typecheck */     \
         _x > _y ? _x : _y;                      \
     })

base-commit: b2c0dc44b37516b758c38de04c61ad295ac0dff2
-- 
2.39.5

Re: [PATCH v2] xen: Use auto as per C23

[Nicola Vetrini]

On 2025-08-15 00:25, Andrew Cooper wrote:
> In macros it is common to declare local variables using typeof(param) 
> in order
> to ensure that side effects are only evaluated once.  A consequence of 
> this is
> double textural expansion of the parameter, which can get out of hand 
> very
> quickly with nested macros.
> 
> In C23, the auto keyword has been repurposed to perform type inference.
> 
> A GCC extension, __auto_type, is now avaialble in the new toolchain 
> baseline
> and avoids the double textural expansion.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

with a nit below:

> ---
> CC: Anthony PERARD <anthony.perard@vates.tech>
> CC: Michal Orzel <michal.orzel@amd.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Julien Grall <julien@xen.org>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Roberto Bagnara <roberto.bagnara@bugseng.com>
> CC: Nicola Vetrini <nicola.vetrini@bugseng.com>
> CC: consulting@bugseng.com <consulting@bugseng.com>
> 
> The resulting build is identical.
> 
> v2:
>  * Use auto directly
>  * Eclair configuration
> 
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1985289434
> ---
>  automation/eclair_analysis/ECLAIR/toolchain.ecl | 11 +++++++++--
>  docs/misra/C-language-toolchain.rst             |  2 ++
>  xen/include/xen/compiler.h                      | 14 ++++++++++++++
>  xen/include/xen/macros.h                        | 14 +++++++-------
>  4 files changed, 32 insertions(+), 9 deletions(-)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/toolchain.ecl 
> b/automation/eclair_analysis/ECLAIR/toolchain.ecl
> index 842f8377e561..125f99a06583 100644
> --- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
> +++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
> @@ -15,6 +15,7 @@
>      __alignof__, __alignof: see Sections \"6.48 Alternate Keywords\" 
> and \"6.44 Determining the Alignment of Functions, Types or Variables\" 
> of "GCC_MANUAL".
>      asm, __asm__: see Sections \"6.48 Alternate Keywords\" and \"6.47 
> How to Use Inline Assembly Language in C Code\" of "GCC_MANUAL".
>      __attribute__: see Section \"6.39 Attribute Syntax\" of 
> "GCC_MANUAL".
> +    __auto_type: see Section \"6.7 Referring to a Type with typeof\" 
> of "GCC_MANUAL".
>      __builtin_offsetof: see Section \"6.53 Support for offsetof\" of 
> "GCC_MANUAL".
>      __builtin_types_compatible_p: see Section \"6.59 Other Built-in 
> Functions Provided by GCC\" of "GCC_MANUAL".
>      __builtin_va_arg: non-documented GCC extension.
> @@ -26,6 +27,7 @@
>  -name_selector+={alignof, "^(__alignof__|__alignof)$"}
>  -name_selector+={asm, "^(__asm__|asm)$"}
>  -name_selector+={attribute, "^__attribute__$"}
> +-name_selector+={auto_type, "^__auto_type$"}
>  -name_selector+={builtin_offsetof, "^__builtin_offsetof$"}
>  -name_selector+={builtin_types_p, "^__builtin_types_compatible_p$"}
>  -name_selector+={builtin_va_arg, "^__builtin_va_arg$"}
> @@ -39,6 +41,7 @@
>  "alignof||
>  asm||
>  attribute||
> +auto_type||
>  builtin_offsetof||
>  builtin_types_p||
>  builtin_va_arg||
> @@ -114,6 +117,7 @@ volatile"
>  -doc_end
> 
>  -doc_begin="
> +    ext_auto_type: see Section \"6.7 Referring to a Type with typeof\" 
> of "GCC_MANUAL".
>      ext_c_missing_varargs_arg: see Section \"6.21 Macros with a 
> Variable Number of Arguments\" of "GCC_MANUAL".
>      ext_enum_value_not_int: non-documented GCC extension.
>      ext_flexible_array_in_array: see Section \"6.18 Arrays of Length 
> Zero\" of "GCC_MANUAL".
> @@ -126,6 +130,7 @@ volatile"
>      ext_return_has_void_expr: see the documentation for -Wreturn-type 
> in Section \"3.8 Options to Request or Suppress Warnings\" of 
> "GCC_MANUAL".
>      ext_sizeof_alignof_void_type: see Section \"6.24 Arithmetic on 
> void- and Function-Pointers\" of "GCC_MANUAL".
>  "
> +-name_selector+={ext_auto_type, "^ext_auto_type$"}
>  -name_selector+={ext_c_missing_varargs_arg, 
> "^ext_c_missing_varargs_arg$"}
>  -name_selector+={ext_enum_value_not_int, "^ext_enum_value_not_int$"}
>  -name_selector+={ext_flexible_array_in_array, 
> "^ext_flexible_array_in_array$"}
> @@ -139,7 +144,8 @@ volatile"
>  -name_selector+={ext_sizeof_alignof_void_type, 
> "^ext_sizeof_alignof_void_type$"}
> 
>  -config=STD.diag,behavior+={c99,GCC_ARM64,
> -"ext_c_missing_varargs_arg||
> +"ext_auto_type||
> +ext_c_missing_varargs_arg||
>  ext_forward_ref_enum_def||
>  ext_gnu_array_range||
>  ext_gnu_statement_expr_macro||
> @@ -149,7 +155,8 @@ ext_return_has_void_expr||
>  ext_sizeof_alignof_void_type"
>  }
>  -config=STD.diag,behavior+={c99,GCC_X86_64,
> -"ext_c_missing_varargs_arg||
> +"ext_auto_type||
> +ext_c_missing_varargs_arg||
>  ext_enum_value_not_int||
>  ext_flexible_array_in_array||
>  ext_flexible_array_in_struct||
> diff --git a/docs/misra/C-language-toolchain.rst 
> b/docs/misra/C-language-toolchain.rst
> index cb81f5c09872..635936004554 100644
> --- a/docs/misra/C-language-toolchain.rst
> +++ b/docs/misra/C-language-toolchain.rst
> @@ -94,6 +94,8 @@ The table columns are as follows:
>            see Sections "6.48 Alternate Keywords" and "6.44 Determining 
> the Alignment of Functions, Types or Variables" of GCC_MANUAL.
>         __attribute__:
>            see Section "6.39 Attribute Syntax" of GCC_MANUAL.
> +       __auto_type:
> +          see Section "6.7 Referring to a Type with typeof" of 
> GCC_MANUAL.
>         __builtin_types_compatible_p:
>            see Section "6.59 Other Built-in Functions Provided by GCC" 
> of GCC_MANUAL.
>         __builtin_va_arg:
> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
> index 88bf26bc5109..38ef5d82ad95 100644
> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -64,6 +64,20 @@
>  # define asm_inline asm
>  #endif
> 
> +/*
> + * In C23, the auto keyword has been repurposed to perform type 
> inference.
> + *
> + * This behaviour is available via the __auto_type extension in 
> supported
> + * toolchains.
> + *
> + * 
> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Auto-Type.html
> + * https://clang.llvm.org/docs/LanguageExtensions.html#auto-type
> + */
> +#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L
> +/* SAF-3-safe MISRA C Rule 20.4: Giving the keyword it's C23 meaning. 
> */
> +#define auto __auto_type
> +#endif
> +

A more detailed explanation should live in deviations.rst under this 
bullet point

    * - R20.4
      - The override of the keyword \"inline\" in xen/compiler.h is 
present so
        that section contents checks pass when the compiler chooses not 
to
        inline a particular function.
      - Comment-based deviation.

as described in the SAF entry:

         {
             "id": "SAF-3-safe",
             "analyser": {
                 "eclair": "MC3A2.R20.4"
             },
             "name": "MC3A2.R20.4: allow the definition of a macro with 
the same name as a keyword in some special cases",
             "text": "The definition of a macro with the same name as a 
keyword can be useful in certain configurations to improve the 
guarantees that can be provided by Xen. See docs/misra/deviations.rst 
for a precise rationale for all such cases."
         },


>  /*
>   * Add the pseudo keyword 'fallthrough' so case statement blocks
>   * must end with any of these keywords:
> diff --git a/xen/include/xen/macros.h b/xen/include/xen/macros.h
> index f9ccde86fb23..ceca2e4a1bf1 100644
> --- a/xen/include/xen/macros.h
> +++ b/xen/include/xen/macros.h
> @@ -63,18 +63,18 @@
>  /* Hide a value from the optimiser. */
>  #define HIDE(x)                                 \
>      ({                                          \
> -        typeof(x) _x = (x);                     \
> +        auto _x = (x);                          \
>          asm volatile ( "" : "+r" (_x) );        \
>          _x;                                     \
>      })
> 
>  #define ABS(x) ({                              \
> -    typeof(x) x_ = (x);                        \
> +    auto x_ = (x);                             \
>      (x_ < 0) ? -x_ : x_;                       \
>  })
> 
>  #define SWAP(a, b) \
> -   do { typeof(a) t_ = (a); (a) = (b); (b) = t_; } while ( 0 )
> +   do { auto t_ = (a); (a) = (b); (b) = t_; } while ( 0 )
> 
>  #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]) + 
> __must_be_array(x))
> 
> @@ -102,15 +102,15 @@
>   */
>  #define min(x, y)                               \
>      ({                                          \
> -        const typeof(x) _x = (x);               \
> -        const typeof(y) _y = (y);               \
> +        const auto _x = (x);                    \
> +        const auto _y = (y);                    \
>          (void)(&_x == &_y); /* typecheck */     \
>          _x < _y ? _x : _y;                      \
>      })
>  #define max(x, y)                               \
>      ({                                          \
> -        const typeof(x) _x = (x);               \
> -        const typeof(y) _y = (y);               \
> +        const auto _x = (x);                    \
> +        const auto _y = (y);                    \
>          (void)(&_x == &_y); /* typecheck */     \
>          _x > _y ? _x : _y;                      \
>      })
> 
> base-commit: b2c0dc44b37516b758c38de04c61ad295ac0dff2

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

Re: [PATCH v2] xen: Use auto as per C23

[Andrew Cooper]

On 15/08/2025 8:20 am, Nicola Vetrini wrote:
> On 2025-08-15 00:25, Andrew Cooper wrote:
>> In macros it is common to declare local variables using typeof(param)
>> in order
>> to ensure that side effects are only evaluated once.  A consequence
>> of this is
>> double textural expansion of the parameter, which can get out of hand
>> very
>> quickly with nested macros.
>>
>> In C23, the auto keyword has been repurposed to perform type inference.
>>
>> A GCC extension, __auto_type, is now avaialble in the new toolchain
>> baseline
>> and avoids the double textural expansion.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>
> Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

Thankyou.

>>
>> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
>> index 88bf26bc5109..38ef5d82ad95 100644
>> --- a/xen/include/xen/compiler.h
>> +++ b/xen/include/xen/compiler.h
>> @@ -64,6 +64,20 @@
>>  # define asm_inline asm
>>  #endif
>>
>> +/*
>> + * In C23, the auto keyword has been repurposed to perform type
>> inference.
>> + *
>> + * This behaviour is available via the __auto_type extension in
>> supported
>> + * toolchains.
>> + *
>> + *
>> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Auto-Type.html
>> + * https://clang.llvm.org/docs/LanguageExtensions.html#auto-type
>> + */
>> +#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L
>> +/* SAF-3-safe MISRA C Rule 20.4: Giving the keyword it's C23
>> meaning. */
>> +#define auto __auto_type
>> +#endif
>> +
>
> A more detailed explanation should live in deviations.rst under this
> bullet point
>
>    * - R20.4
>      - The override of the keyword \"inline\" in xen/compiler.h is
> present so
>        that section contents checks pass when the compiler chooses not to
>        inline a particular function.
>      - Comment-based deviation.
>
> as described in the SAF entry:
>
>         {
>             "id": "SAF-3-safe",
>             "analyser": {
>                 "eclair": "MC3A2.R20.4"
>             },
>             "name": "MC3A2.R20.4: allow the definition of a macro with
> the same name as a keyword in some special cases",
>             "text": "The definition of a macro with the same name as a
> keyword can be useful in certain configurations to improve the
> guarantees that can be provided by Xen. See docs/misra/deviations.rst
> for a precise rationale for all such cases."
>         },

Ah right.  What about this:

"Xen does not use the \"auto\" keyword as a storage qualifier.  The
override of the keyword \"auto\" in xen/compiler.h is to give it it's
C23 behaviour of type inference."

?

~Andrew

P.S. I thought that final fix was too easy.  Your instructions for the
main config were spot on and worked first time, except for getting the
R20.4 violation too.

Re: [PATCH v2] xen: Use auto as per C23

[Nicola Vetrini]

On 2025-08-15 10:17, Andrew Cooper wrote:
> On 15/08/2025 8:20 am, Nicola Vetrini wrote:
>> On 2025-08-15 00:25, Andrew Cooper wrote:
>>> In macros it is common to declare local variables using typeof(param)
>>> in order
>>> to ensure that side effects are only evaluated once.  A consequence
>>> of this is
>>> double textural expansion of the parameter, which can get out of hand
>>> very
>>> quickly with nested macros.
>>> 
>>> In C23, the auto keyword has been repurposed to perform type 
>>> inference.
>>> 
>>> A GCC extension, __auto_type, is now avaialble in the new toolchain
>>> baseline
>>> and avoids the double textural expansion.
>>> 
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> 
>> Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> 
> Thankyou.
> 
>>> 
>>> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
>>> index 88bf26bc5109..38ef5d82ad95 100644
>>> --- a/xen/include/xen/compiler.h
>>> +++ b/xen/include/xen/compiler.h
>>> @@ -64,6 +64,20 @@
>>>  # define asm_inline asm
>>>  #endif
>>> 
>>> +/*
>>> + * In C23, the auto keyword has been repurposed to perform type
>>> inference.
>>> + *
>>> + * This behaviour is available via the __auto_type extension in
>>> supported
>>> + * toolchains.
>>> + *
>>> + *
>>> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Auto-Type.html
>>> + * https://clang.llvm.org/docs/LanguageExtensions.html#auto-type
>>> + */
>>> +#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L
>>> +/* SAF-3-safe MISRA C Rule 20.4: Giving the keyword it's C23
>>> meaning. */
>>> +#define auto __auto_type
>>> +#endif
>>> +
>> 
>> A more detailed explanation should live in deviations.rst under this
>> bullet point
>> 
>>    * - R20.4
>>      - The override of the keyword \"inline\" in xen/compiler.h is
>> present so
>>        that section contents checks pass when the compiler chooses not 
>> to
>>        inline a particular function.
>>      - Comment-based deviation.
>> 
>> as described in the SAF entry:
>> 
>>         {
>>             "id": "SAF-3-safe",
>>             "analyser": {
>>                 "eclair": "MC3A2.R20.4"
>>             },
>>             "name": "MC3A2.R20.4: allow the definition of a macro with
>> the same name as a keyword in some special cases",
>>             "text": "The definition of a macro with the same name as a
>> keyword can be useful in certain configurations to improve the
>> guarantees that can be provided by Xen. See docs/misra/deviations.rst
>> for a precise rationale for all such cases."
>>         },
> 
> Ah right.  What about this:
> 
> "Xen does not use the \"auto\" keyword as a storage qualifier.  The
> override of the keyword \"auto\" in xen/compiler.h is to give it it's
> C23 behaviour of type inference."
> 
> ?
> 

Seems good to me. Maybe this should be spelled out in ./CODING_STYLE as 
well, so that newcomers don't trip over this?

> ~Andrew
> 
> P.S. I thought that final fix was too easy.  Your instructions for the
> main config were spot on and worked first time, except for getting the
> R20.4 violation too.

Yeah, forgot about that one; it's not so common to override keywords.

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

Re: [PATCH v2] xen: Use auto as per C23

[Jan Beulich]

On 15.08.2025 10:33, Nicola Vetrini wrote:
> On 2025-08-15 10:17, Andrew Cooper wrote:
>> On 15/08/2025 8:20 am, Nicola Vetrini wrote:
>>> On 2025-08-15 00:25, Andrew Cooper wrote:
>>>> In macros it is common to declare local variables using typeof(param)
>>>> in order
>>>> to ensure that side effects are only evaluated once.  A consequence
>>>> of this is
>>>> double textural expansion of the parameter, which can get out of hand
>>>> very
>>>> quickly with nested macros.
>>>>
>>>> In C23, the auto keyword has been repurposed to perform type 
>>>> inference.
>>>>
>>>> A GCC extension, __auto_type, is now avaialble in the new toolchain
>>>> baseline
>>>> and avoids the double textural expansion.
>>>>
>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>
>>> Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>>
>> Thankyou.
>>
>>>>
>>>> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
>>>> index 88bf26bc5109..38ef5d82ad95 100644
>>>> --- a/xen/include/xen/compiler.h
>>>> +++ b/xen/include/xen/compiler.h
>>>> @@ -64,6 +64,20 @@
>>>>  # define asm_inline asm
>>>>  #endif
>>>>
>>>> +/*
>>>> + * In C23, the auto keyword has been repurposed to perform type
>>>> inference.
>>>> + *
>>>> + * This behaviour is available via the __auto_type extension in
>>>> supported
>>>> + * toolchains.
>>>> + *
>>>> + *
>>>> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Auto-Type.html
>>>> + * https://clang.llvm.org/docs/LanguageExtensions.html#auto-type
>>>> + */
>>>> +#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L
>>>> +/* SAF-3-safe MISRA C Rule 20.4: Giving the keyword it's C23
>>>> meaning. */
>>>> +#define auto __auto_type
>>>> +#endif
>>>> +
>>>
>>> A more detailed explanation should live in deviations.rst under this
>>> bullet point
>>>
>>>    * - R20.4
>>>      - The override of the keyword \"inline\" in xen/compiler.h is
>>> present so
>>>        that section contents checks pass when the compiler chooses not 
>>> to
>>>        inline a particular function.
>>>      - Comment-based deviation.
>>>
>>> as described in the SAF entry:
>>>
>>>         {
>>>             "id": "SAF-3-safe",
>>>             "analyser": {
>>>                 "eclair": "MC3A2.R20.4"
>>>             },
>>>             "name": "MC3A2.R20.4: allow the definition of a macro with
>>> the same name as a keyword in some special cases",
>>>             "text": "The definition of a macro with the same name as a
>>> keyword can be useful in certain configurations to improve the
>>> guarantees that can be provided by Xen. See docs/misra/deviations.rst
>>> for a precise rationale for all such cases."
>>>         },
>>
>> Ah right.  What about this:
>>
>> "Xen does not use the \"auto\" keyword as a storage qualifier.  The
>> override of the keyword \"auto\" in xen/compiler.h is to give it it's
>> C23 behaviour of type inference."
>>
>> ?
> 
> Seems good to me. Maybe this should be spelled out in ./CODING_STYLE as 
> well, so that newcomers don't trip over this?

I'm not sure newcomers would look there, but in the absence of any better
place that's perhaps indeed where to mention this.

I am, however, still not quite sure if we're doing ourselves a favor with
the re-purposing of auto (while not using C23 in general). It'll certainly
hit me as unexpected, for some time, to see uses of the keyword. It simply
has been for too long that it had its earlier meaning (of very limited use).

Jan

Re: [PATCH v2] xen: Use auto as per C23

[Andrew Cooper]

On 15/08/2025 10:36 am, Jan Beulich wrote:
> On 15.08.2025 10:33, Nicola Vetrini wrote:
>> On 2025-08-15 10:17, Andrew Cooper wrote:
>>> On 15/08/2025 8:20 am, Nicola Vetrini wrote:
>>>> On 2025-08-15 00:25, Andrew Cooper wrote:
>>>>> In macros it is common to declare local variables using typeof(param)
>>>>> in order
>>>>> to ensure that side effects are only evaluated once.  A consequence
>>>>> of this is
>>>>> double textural expansion of the parameter, which can get out of hand
>>>>> very
>>>>> quickly with nested macros.
>>>>>
>>>>> In C23, the auto keyword has been repurposed to perform type 
>>>>> inference.
>>>>>
>>>>> A GCC extension, __auto_type, is now avaialble in the new toolchain
>>>>> baseline
>>>>> and avoids the double textural expansion.
>>>>>
>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>> Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>>> Thankyou.
>>>
>>>>> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
>>>>> index 88bf26bc5109..38ef5d82ad95 100644
>>>>> --- a/xen/include/xen/compiler.h
>>>>> +++ b/xen/include/xen/compiler.h
>>>>> @@ -64,6 +64,20 @@
>>>>>  # define asm_inline asm
>>>>>  #endif
>>>>>
>>>>> +/*
>>>>> + * In C23, the auto keyword has been repurposed to perform type
>>>>> inference.
>>>>> + *
>>>>> + * This behaviour is available via the __auto_type extension in
>>>>> supported
>>>>> + * toolchains.
>>>>> + *
>>>>> + *
>>>>> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Auto-Type.html
>>>>> + * https://clang.llvm.org/docs/LanguageExtensions.html#auto-type
>>>>> + */
>>>>> +#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L
>>>>> +/* SAF-3-safe MISRA C Rule 20.4: Giving the keyword it's C23
>>>>> meaning. */
>>>>> +#define auto __auto_type
>>>>> +#endif
>>>>> +
>>>> A more detailed explanation should live in deviations.rst under this
>>>> bullet point
>>>>
>>>>    * - R20.4
>>>>      - The override of the keyword \"inline\" in xen/compiler.h is
>>>> present so
>>>>        that section contents checks pass when the compiler chooses not 
>>>> to
>>>>        inline a particular function.
>>>>      - Comment-based deviation.
>>>>
>>>> as described in the SAF entry:
>>>>
>>>>         {
>>>>             "id": "SAF-3-safe",
>>>>             "analyser": {
>>>>                 "eclair": "MC3A2.R20.4"
>>>>             },
>>>>             "name": "MC3A2.R20.4: allow the definition of a macro with
>>>> the same name as a keyword in some special cases",
>>>>             "text": "The definition of a macro with the same name as a
>>>> keyword can be useful in certain configurations to improve the
>>>> guarantees that can be provided by Xen. See docs/misra/deviations.rst
>>>> for a precise rationale for all such cases."
>>>>         },
>>> Ah right.  What about this:
>>>
>>> "Xen does not use the \"auto\" keyword as a storage qualifier.  The
>>> override of the keyword \"auto\" in xen/compiler.h is to give it it's
>>> C23 behaviour of type inference."
>>>
>>> ?
>> Seems good to me. Maybe this should be spelled out in ./CODING_STYLE as 
>> well, so that newcomers don't trip over this?
> I'm not sure newcomers would look there, but in the absence of any better
> place that's perhaps indeed where to mention this.

How about this:

diff --git a/CODING_STYLE b/CODING_STYLE
index 7bf3848444ad..e33b9d1170cf 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -129,6 +129,10 @@ Fixed width types should only be used when a fixed width quantity is
 meant (which for example may be a value read from or to be written to a
 register).
 
+Macros which otherwise would use "typeof(arg) newarg =" to avoid double
+evaluation of side effects should use "auto newarg =" per it's C23 behaviour,
+to also avoid double textural expansion.
+
 Especially with pointer types, whenever the pointed to object is not
 (supposed to be) modified, qualify the pointed to type with "const".



>
> I am, however, still not quite sure if we're doing ourselves a favor with
> the re-purposing of auto (while not using C23 in general). It'll certainly
> hit me as unexpected, for some time, to see uses of the keyword. It simply
> has been for too long that it had its earlier meaning (of very limited use).

I suspect that people won't find this great reasoning, but here's how I
see it.

Linux already does this, so familiarity in wider circles is growing. 
Now C23 is available, people starting new projects will be using it,
which will normalise the construct further.

People are going to be forced to get used to it, one way or another. 
They can simply choose whether it's now, or later.

Within Xen, the scope is narrow.  I am specifically not advocating that
we get it used outside of macros.

~Andrew

Re: [PATCH v2] xen: Use auto as per C23

[Jan Beulich]

On 15.08.2025 11:51, Andrew Cooper wrote:
> On 15/08/2025 10:36 am, Jan Beulich wrote:
>> On 15.08.2025 10:33, Nicola Vetrini wrote:
>>> On 2025-08-15 10:17, Andrew Cooper wrote:
>>>> On 15/08/2025 8:20 am, Nicola Vetrini wrote:
>>>>> On 2025-08-15 00:25, Andrew Cooper wrote:
>>>>>> In macros it is common to declare local variables using typeof(param)
>>>>>> in order
>>>>>> to ensure that side effects are only evaluated once.  A consequence
>>>>>> of this is
>>>>>> double textural expansion of the parameter, which can get out of hand
>>>>>> very
>>>>>> quickly with nested macros.
>>>>>>
>>>>>> In C23, the auto keyword has been repurposed to perform type 
>>>>>> inference.
>>>>>>
>>>>>> A GCC extension, __auto_type, is now avaialble in the new toolchain
>>>>>> baseline
>>>>>> and avoids the double textural expansion.
>>>>>>
>>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>> Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>>>> Thankyou.
>>>>
>>>>>> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
>>>>>> index 88bf26bc5109..38ef5d82ad95 100644
>>>>>> --- a/xen/include/xen/compiler.h
>>>>>> +++ b/xen/include/xen/compiler.h
>>>>>> @@ -64,6 +64,20 @@
>>>>>>  # define asm_inline asm
>>>>>>  #endif
>>>>>>
>>>>>> +/*
>>>>>> + * In C23, the auto keyword has been repurposed to perform type
>>>>>> inference.
>>>>>> + *
>>>>>> + * This behaviour is available via the __auto_type extension in
>>>>>> supported
>>>>>> + * toolchains.
>>>>>> + *
>>>>>> + *
>>>>>> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Auto-Type.html
>>>>>> + * https://clang.llvm.org/docs/LanguageExtensions.html#auto-type
>>>>>> + */
>>>>>> +#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L
>>>>>> +/* SAF-3-safe MISRA C Rule 20.4: Giving the keyword it's C23
>>>>>> meaning. */
>>>>>> +#define auto __auto_type
>>>>>> +#endif
>>>>>> +
>>>>> A more detailed explanation should live in deviations.rst under this
>>>>> bullet point
>>>>>
>>>>>    * - R20.4
>>>>>      - The override of the keyword \"inline\" in xen/compiler.h is
>>>>> present so
>>>>>        that section contents checks pass when the compiler chooses not 
>>>>> to
>>>>>        inline a particular function.
>>>>>      - Comment-based deviation.
>>>>>
>>>>> as described in the SAF entry:
>>>>>
>>>>>         {
>>>>>             "id": "SAF-3-safe",
>>>>>             "analyser": {
>>>>>                 "eclair": "MC3A2.R20.4"
>>>>>             },
>>>>>             "name": "MC3A2.R20.4: allow the definition of a macro with
>>>>> the same name as a keyword in some special cases",
>>>>>             "text": "The definition of a macro with the same name as a
>>>>> keyword can be useful in certain configurations to improve the
>>>>> guarantees that can be provided by Xen. See docs/misra/deviations.rst
>>>>> for a precise rationale for all such cases."
>>>>>         },
>>>> Ah right.  What about this:
>>>>
>>>> "Xen does not use the \"auto\" keyword as a storage qualifier.  The
>>>> override of the keyword \"auto\" in xen/compiler.h is to give it it's
>>>> C23 behaviour of type inference."
>>>>
>>>> ?
>>> Seems good to me. Maybe this should be spelled out in ./CODING_STYLE as 
>>> well, so that newcomers don't trip over this?
>> I'm not sure newcomers would look there, but in the absence of any better
>> place that's perhaps indeed where to mention this.
> 
> How about this:
> 
> diff --git a/CODING_STYLE b/CODING_STYLE
> index 7bf3848444ad..e33b9d1170cf 100644
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -129,6 +129,10 @@ Fixed width types should only be used when a fixed width quantity is
>  meant (which for example may be a value read from or to be written to a
>  register).
>  
> +Macros which otherwise would use "typeof(arg) newarg =" to avoid double
> +evaluation of side effects should use "auto newarg =" per it's C23 behaviour,
> +to also avoid double textural expansion.
> +
>  Especially with pointer types, whenever the pointed to object is not
>  (supposed to be) modified, qualify the pointed to type with "const".

That doesn't focus on the pitfall though, in that people shouldn't be using
the "auto" keyword (except in said cases).

Jan

Re: [PATCH v2] xen: Use auto as per C23

[Andrew Cooper]

On 15/08/2025 11:25 am, Jan Beulich wrote:
> On 15.08.2025 11:51, Andrew Cooper wrote:
>> On 15/08/2025 10:36 am, Jan Beulich wrote:
>>> On 15.08.2025 10:33, Nicola Vetrini wrote:
>>>> On 2025-08-15 10:17, Andrew Cooper wrote:
>>>>> On 15/08/2025 8:20 am, Nicola Vetrini wrote:
>>>>>> On 2025-08-15 00:25, Andrew Cooper wrote:
>>>>>>> In macros it is common to declare local variables using typeof(param)
>>>>>>> in order
>>>>>>> to ensure that side effects are only evaluated once.  A consequence
>>>>>>> of this is
>>>>>>> double textural expansion of the parameter, which can get out of hand
>>>>>>> very
>>>>>>> quickly with nested macros.
>>>>>>>
>>>>>>> In C23, the auto keyword has been repurposed to perform type 
>>>>>>> inference.
>>>>>>>
>>>>>>> A GCC extension, __auto_type, is now avaialble in the new toolchain
>>>>>>> baseline
>>>>>>> and avoids the double textural expansion.
>>>>>>>
>>>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>> Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>>>>> Thankyou.
>>>>>
>>>>>>> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
>>>>>>> index 88bf26bc5109..38ef5d82ad95 100644
>>>>>>> --- a/xen/include/xen/compiler.h
>>>>>>> +++ b/xen/include/xen/compiler.h
>>>>>>> @@ -64,6 +64,20 @@
>>>>>>>  # define asm_inline asm
>>>>>>>  #endif
>>>>>>>
>>>>>>> +/*
>>>>>>> + * In C23, the auto keyword has been repurposed to perform type
>>>>>>> inference.
>>>>>>> + *
>>>>>>> + * This behaviour is available via the __auto_type extension in
>>>>>>> supported
>>>>>>> + * toolchains.
>>>>>>> + *
>>>>>>> + *
>>>>>>> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Auto-Type.html
>>>>>>> + * https://clang.llvm.org/docs/LanguageExtensions.html#auto-type
>>>>>>> + */
>>>>>>> +#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L
>>>>>>> +/* SAF-3-safe MISRA C Rule 20.4: Giving the keyword it's C23
>>>>>>> meaning. */
>>>>>>> +#define auto __auto_type
>>>>>>> +#endif
>>>>>>> +
>>>>>> A more detailed explanation should live in deviations.rst under this
>>>>>> bullet point
>>>>>>
>>>>>>    * - R20.4
>>>>>>      - The override of the keyword \"inline\" in xen/compiler.h is
>>>>>> present so
>>>>>>        that section contents checks pass when the compiler chooses not 
>>>>>> to
>>>>>>        inline a particular function.
>>>>>>      - Comment-based deviation.
>>>>>>
>>>>>> as described in the SAF entry:
>>>>>>
>>>>>>         {
>>>>>>             "id": "SAF-3-safe",
>>>>>>             "analyser": {
>>>>>>                 "eclair": "MC3A2.R20.4"
>>>>>>             },
>>>>>>             "name": "MC3A2.R20.4: allow the definition of a macro with
>>>>>> the same name as a keyword in some special cases",
>>>>>>             "text": "The definition of a macro with the same name as a
>>>>>> keyword can be useful in certain configurations to improve the
>>>>>> guarantees that can be provided by Xen. See docs/misra/deviations.rst
>>>>>> for a precise rationale for all such cases."
>>>>>>         },
>>>>> Ah right.  What about this:
>>>>>
>>>>> "Xen does not use the \"auto\" keyword as a storage qualifier.  The
>>>>> override of the keyword \"auto\" in xen/compiler.h is to give it it's
>>>>> C23 behaviour of type inference."
>>>>>
>>>>> ?
>>>> Seems good to me. Maybe this should be spelled out in ./CODING_STYLE as 
>>>> well, so that newcomers don't trip over this?
>>> I'm not sure newcomers would look there, but in the absence of any better
>>> place that's perhaps indeed where to mention this.
>> How about this:
>>
>> diff --git a/CODING_STYLE b/CODING_STYLE
>> index 7bf3848444ad..e33b9d1170cf 100644
>> --- a/CODING_STYLE
>> +++ b/CODING_STYLE
>> @@ -129,6 +129,10 @@ Fixed width types should only be used when a fixed width quantity is
>>  meant (which for example may be a value read from or to be written to a
>>  register).
>>  
>> +Macros which otherwise would use "typeof(arg) newarg =" to avoid double
>> +evaluation of side effects should use "auto newarg =" per it's C23 behaviour,
>> +to also avoid double textural expansion.
>> +
>>  Especially with pointer types, whenever the pointed to object is not
>>  (supposed to be) modified, qualify the pointed to type with "const".
> That doesn't focus on the pitfall though, in that people shouldn't be using
> the "auto" keyword (except in said cases).

/sigh, this is why noone does patches to CODING_STYLE.

If you don't like the wording, propose some wording that you do like.

Or I will commit the patch without this hunk, because I'm not going to
get drawn into the cycle of blind guessing that every change to
CODING_STYLE seems to get caught in.

~Andrew

Re: [PATCH v2] xen: Use auto as per C23

[Jan Beulich]

On 15.08.2025 12:53, Andrew Cooper wrote:
> On 15/08/2025 11:25 am, Jan Beulich wrote:
>> On 15.08.2025 11:51, Andrew Cooper wrote:
>>> On 15/08/2025 10:36 am, Jan Beulich wrote:
>>>> On 15.08.2025 10:33, Nicola Vetrini wrote:
>>>>> On 2025-08-15 10:17, Andrew Cooper wrote:
>>>>>> On 15/08/2025 8:20 am, Nicola Vetrini wrote:
>>>>>>> On 2025-08-15 00:25, Andrew Cooper wrote:
>>>>>>>> In macros it is common to declare local variables using typeof(param)
>>>>>>>> in order
>>>>>>>> to ensure that side effects are only evaluated once.  A consequence
>>>>>>>> of this is
>>>>>>>> double textural expansion of the parameter, which can get out of hand
>>>>>>>> very
>>>>>>>> quickly with nested macros.
>>>>>>>>
>>>>>>>> In C23, the auto keyword has been repurposed to perform type 
>>>>>>>> inference.
>>>>>>>>
>>>>>>>> A GCC extension, __auto_type, is now avaialble in the new toolchain
>>>>>>>> baseline
>>>>>>>> and avoids the double textural expansion.
>>>>>>>>
>>>>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>>> Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>>>>>> Thankyou.
>>>>>>
>>>>>>>> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
>>>>>>>> index 88bf26bc5109..38ef5d82ad95 100644
>>>>>>>> --- a/xen/include/xen/compiler.h
>>>>>>>> +++ b/xen/include/xen/compiler.h
>>>>>>>> @@ -64,6 +64,20 @@
>>>>>>>>  # define asm_inline asm
>>>>>>>>  #endif
>>>>>>>>
>>>>>>>> +/*
>>>>>>>> + * In C23, the auto keyword has been repurposed to perform type
>>>>>>>> inference.
>>>>>>>> + *
>>>>>>>> + * This behaviour is available via the __auto_type extension in
>>>>>>>> supported
>>>>>>>> + * toolchains.
>>>>>>>> + *
>>>>>>>> + *
>>>>>>>> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Auto-Type.html
>>>>>>>> + * https://clang.llvm.org/docs/LanguageExtensions.html#auto-type
>>>>>>>> + */
>>>>>>>> +#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L
>>>>>>>> +/* SAF-3-safe MISRA C Rule 20.4: Giving the keyword it's C23
>>>>>>>> meaning. */
>>>>>>>> +#define auto __auto_type
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>> A more detailed explanation should live in deviations.rst under this
>>>>>>> bullet point
>>>>>>>
>>>>>>>    * - R20.4
>>>>>>>      - The override of the keyword \"inline\" in xen/compiler.h is
>>>>>>> present so
>>>>>>>        that section contents checks pass when the compiler chooses not 
>>>>>>> to
>>>>>>>        inline a particular function.
>>>>>>>      - Comment-based deviation.
>>>>>>>
>>>>>>> as described in the SAF entry:
>>>>>>>
>>>>>>>         {
>>>>>>>             "id": "SAF-3-safe",
>>>>>>>             "analyser": {
>>>>>>>                 "eclair": "MC3A2.R20.4"
>>>>>>>             },
>>>>>>>             "name": "MC3A2.R20.4: allow the definition of a macro with
>>>>>>> the same name as a keyword in some special cases",
>>>>>>>             "text": "The definition of a macro with the same name as a
>>>>>>> keyword can be useful in certain configurations to improve the
>>>>>>> guarantees that can be provided by Xen. See docs/misra/deviations.rst
>>>>>>> for a precise rationale for all such cases."
>>>>>>>         },
>>>>>> Ah right.  What about this:
>>>>>>
>>>>>> "Xen does not use the \"auto\" keyword as a storage qualifier.  The
>>>>>> override of the keyword \"auto\" in xen/compiler.h is to give it it's
>>>>>> C23 behaviour of type inference."
>>>>>>
>>>>>> ?
>>>>> Seems good to me. Maybe this should be spelled out in ./CODING_STYLE as 
>>>>> well, so that newcomers don't trip over this?
>>>> I'm not sure newcomers would look there, but in the absence of any better
>>>> place that's perhaps indeed where to mention this.
>>> How about this:
>>>
>>> diff --git a/CODING_STYLE b/CODING_STYLE
>>> index 7bf3848444ad..e33b9d1170cf 100644
>>> --- a/CODING_STYLE
>>> +++ b/CODING_STYLE
>>> @@ -129,6 +129,10 @@ Fixed width types should only be used when a fixed width quantity is
>>>  meant (which for example may be a value read from or to be written to a
>>>  register).
>>>  
>>> +Macros which otherwise would use "typeof(arg) newarg =" to avoid double
>>> +evaluation of side effects should use "auto newarg =" per it's C23 behaviour,
>>> +to also avoid double textural expansion.
>>> +
>>>  Especially with pointer types, whenever the pointed to object is not
>>>  (supposed to be) modified, qualify the pointed to type with "const".
>> That doesn't focus on the pitfall though, in that people shouldn't be using
>> the "auto" keyword (except in said cases).
> 
> /sigh, this is why noone does patches to CODING_STYLE.
> 
> If you don't like the wording, propose some wording that you do like.
> 
> Or I will commit the patch without this hunk, because I'm not going to
> get drawn into the cycle of blind guessing that every change to
> CODING_STYLE seems to get caught in.

I don't care about the wording; what I do care about is to get the caveat
across. Maybe:

'"auto" isn't used in its traditional sense, but rather with its C23 meaning.
 Such uses are intended to be limited to macro-local variables.'

Jan

Re: [PATCH v2] xen: Use auto as per C23

[Frediano Ziglio]

On Fri, Aug 15, 2025 at 1:28 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 15.08.2025 12:53, Andrew Cooper wrote:
> > On 15/08/2025 11:25 am, Jan Beulich wrote:
> >> On 15.08.2025 11:51, Andrew Cooper wrote:
> >>> On 15/08/2025 10:36 am, Jan Beulich wrote:
> >>>> On 15.08.2025 10:33, Nicola Vetrini wrote:
> >>>>> On 2025-08-15 10:17, Andrew Cooper wrote:
> >>>>>> On 15/08/2025 8:20 am, Nicola Vetrini wrote:
> >>>>>>> On 2025-08-15 00:25, Andrew Cooper wrote:
> >>>>>>>> In macros it is common to declare local variables using typeof(param)
> >>>>>>>> in order
> >>>>>>>> to ensure that side effects are only evaluated once.  A consequence
> >>>>>>>> of this is
> >>>>>>>> double textural expansion of the parameter, which can get out of hand
> >>>>>>>> very
> >>>>>>>> quickly with nested macros.
> >>>>>>>>
> >>>>>>>> In C23, the auto keyword has been repurposed to perform type
> >>>>>>>> inference.
> >>>>>>>>
> >>>>>>>> A GCC extension, __auto_type, is now avaialble in the new toolchain
> >>>>>>>> baseline
> >>>>>>>> and avoids the double textural expansion.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >>>>>>> Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> >>>>>> Thankyou.
> >>>>>>
> >>>>>>>> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
> >>>>>>>> index 88bf26bc5109..38ef5d82ad95 100644
> >>>>>>>> --- a/xen/include/xen/compiler.h
> >>>>>>>> +++ b/xen/include/xen/compiler.h
> >>>>>>>> @@ -64,6 +64,20 @@
> >>>>>>>>  # define asm_inline asm
> >>>>>>>>  #endif
> >>>>>>>>
> >>>>>>>> +/*
> >>>>>>>> + * In C23, the auto keyword has been repurposed to perform type
> >>>>>>>> inference.
> >>>>>>>> + *
> >>>>>>>> + * This behaviour is available via the __auto_type extension in
> >>>>>>>> supported
> >>>>>>>> + * toolchains.
> >>>>>>>> + *
> >>>>>>>> + *
> >>>>>>>> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Auto-Type.html
> >>>>>>>> + * https://clang.llvm.org/docs/LanguageExtensions.html#auto-type
> >>>>>>>> + */
> >>>>>>>> +#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L
> >>>>>>>> +/* SAF-3-safe MISRA C Rule 20.4: Giving the keyword it's C23
> >>>>>>>> meaning. */
> >>>>>>>> +#define auto __auto_type
> >>>>>>>> +#endif
> >>>>>>>> +
> >>>>>>> A more detailed explanation should live in deviations.rst under this
> >>>>>>> bullet point
> >>>>>>>
> >>>>>>>    * - R20.4
> >>>>>>>      - The override of the keyword \"inline\" in xen/compiler.h is
> >>>>>>> present so
> >>>>>>>        that section contents checks pass when the compiler chooses not
> >>>>>>> to
> >>>>>>>        inline a particular function.
> >>>>>>>      - Comment-based deviation.
> >>>>>>>
> >>>>>>> as described in the SAF entry:
> >>>>>>>
> >>>>>>>         {
> >>>>>>>             "id": "SAF-3-safe",
> >>>>>>>             "analyser": {
> >>>>>>>                 "eclair": "MC3A2.R20.4"
> >>>>>>>             },
> >>>>>>>             "name": "MC3A2.R20.4: allow the definition of a macro with
> >>>>>>> the same name as a keyword in some special cases",
> >>>>>>>             "text": "The definition of a macro with the same name as a
> >>>>>>> keyword can be useful in certain configurations to improve the
> >>>>>>> guarantees that can be provided by Xen. See docs/misra/deviations.rst
> >>>>>>> for a precise rationale for all such cases."
> >>>>>>>         },
> >>>>>> Ah right.  What about this:
> >>>>>>
> >>>>>> "Xen does not use the \"auto\" keyword as a storage qualifier.  The
> >>>>>> override of the keyword \"auto\" in xen/compiler.h is to give it it's
> >>>>>> C23 behaviour of type inference."
> >>>>>>
> >>>>>> ?
> >>>>> Seems good to me. Maybe this should be spelled out in ./CODING_STYLE as
> >>>>> well, so that newcomers don't trip over this?
> >>>> I'm not sure newcomers would look there, but in the absence of any better
> >>>> place that's perhaps indeed where to mention this.
> >>> How about this:
> >>>
> >>> diff --git a/CODING_STYLE b/CODING_STYLE
> >>> index 7bf3848444ad..e33b9d1170cf 100644
> >>> --- a/CODING_STYLE
> >>> +++ b/CODING_STYLE
> >>> @@ -129,6 +129,10 @@ Fixed width types should only be used when a fixed width quantity is
> >>>  meant (which for example may be a value read from or to be written to a
> >>>  register).
> >>>
> >>> +Macros which otherwise would use "typeof(arg) newarg =" to avoid double
> >>> +evaluation of side effects should use "auto newarg =" per it's C23 behaviour,
> >>> +to also avoid double textural expansion.
> >>> +
> >>>  Especially with pointer types, whenever the pointed to object is not
> >>>  (supposed to be) modified, qualify the pointed to type with "const".
> >> That doesn't focus on the pitfall though, in that people shouldn't be using
> >> the "auto" keyword (except in said cases).
> >
> > /sigh, this is why noone does patches to CODING_STYLE.
> >
> > If you don't like the wording, propose some wording that you do like.
> >
> > Or I will commit the patch without this hunk, because I'm not going to
> > get drawn into the cycle of blind guessing that every change to
> > CODING_STYLE seems to get caught in.
>
> I don't care about the wording; what I do care about is to get the caveat
> across. Maybe:
>
> '"auto" isn't used in its traditional sense, but rather with its C23 meaning.
>  Such uses are intended to be limited to macro-local variables.'
>

Why limiting to macros?

> Jan
>

Frediano

Re: [PATCH v2] xen: Use auto as per C23

[Jan Beulich]

On 15.08.2025 14:35, Frediano Ziglio wrote:
> On Fri, Aug 15, 2025 at 1:28 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 15.08.2025 12:53, Andrew Cooper wrote:
>>> On 15/08/2025 11:25 am, Jan Beulich wrote:
>>>> On 15.08.2025 11:51, Andrew Cooper wrote:
>>>>> On 15/08/2025 10:36 am, Jan Beulich wrote:
>>>>>> On 15.08.2025 10:33, Nicola Vetrini wrote:
>>>>>>> On 2025-08-15 10:17, Andrew Cooper wrote:
>>>>>>>> On 15/08/2025 8:20 am, Nicola Vetrini wrote:
>>>>>>>>> On 2025-08-15 00:25, Andrew Cooper wrote:
>>>>>>>>>> In macros it is common to declare local variables using typeof(param)
>>>>>>>>>> in order
>>>>>>>>>> to ensure that side effects are only evaluated once.  A consequence
>>>>>>>>>> of this is
>>>>>>>>>> double textural expansion of the parameter, which can get out of hand
>>>>>>>>>> very
>>>>>>>>>> quickly with nested macros.
>>>>>>>>>>
>>>>>>>>>> In C23, the auto keyword has been repurposed to perform type
>>>>>>>>>> inference.
>>>>>>>>>>
>>>>>>>>>> A GCC extension, __auto_type, is now avaialble in the new toolchain
>>>>>>>>>> baseline
>>>>>>>>>> and avoids the double textural expansion.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>>>>> Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>>>>>>>> Thankyou.
>>>>>>>>
>>>>>>>>>> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
>>>>>>>>>> index 88bf26bc5109..38ef5d82ad95 100644
>>>>>>>>>> --- a/xen/include/xen/compiler.h
>>>>>>>>>> +++ b/xen/include/xen/compiler.h
>>>>>>>>>> @@ -64,6 +64,20 @@
>>>>>>>>>>  # define asm_inline asm
>>>>>>>>>>  #endif
>>>>>>>>>>
>>>>>>>>>> +/*
>>>>>>>>>> + * In C23, the auto keyword has been repurposed to perform type
>>>>>>>>>> inference.
>>>>>>>>>> + *
>>>>>>>>>> + * This behaviour is available via the __auto_type extension in
>>>>>>>>>> supported
>>>>>>>>>> + * toolchains.
>>>>>>>>>> + *
>>>>>>>>>> + *
>>>>>>>>>> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Auto-Type.html
>>>>>>>>>> + * https://clang.llvm.org/docs/LanguageExtensions.html#auto-type
>>>>>>>>>> + */
>>>>>>>>>> +#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L
>>>>>>>>>> +/* SAF-3-safe MISRA C Rule 20.4: Giving the keyword it's C23
>>>>>>>>>> meaning. */
>>>>>>>>>> +#define auto __auto_type
>>>>>>>>>> +#endif
>>>>>>>>>> +
>>>>>>>>> A more detailed explanation should live in deviations.rst under this
>>>>>>>>> bullet point
>>>>>>>>>
>>>>>>>>>    * - R20.4
>>>>>>>>>      - The override of the keyword \"inline\" in xen/compiler.h is
>>>>>>>>> present so
>>>>>>>>>        that section contents checks pass when the compiler chooses not
>>>>>>>>> to
>>>>>>>>>        inline a particular function.
>>>>>>>>>      - Comment-based deviation.
>>>>>>>>>
>>>>>>>>> as described in the SAF entry:
>>>>>>>>>
>>>>>>>>>         {
>>>>>>>>>             "id": "SAF-3-safe",
>>>>>>>>>             "analyser": {
>>>>>>>>>                 "eclair": "MC3A2.R20.4"
>>>>>>>>>             },
>>>>>>>>>             "name": "MC3A2.R20.4: allow the definition of a macro with
>>>>>>>>> the same name as a keyword in some special cases",
>>>>>>>>>             "text": "The definition of a macro with the same name as a
>>>>>>>>> keyword can be useful in certain configurations to improve the
>>>>>>>>> guarantees that can be provided by Xen. See docs/misra/deviations.rst
>>>>>>>>> for a precise rationale for all such cases."
>>>>>>>>>         },
>>>>>>>> Ah right.  What about this:
>>>>>>>>
>>>>>>>> "Xen does not use the \"auto\" keyword as a storage qualifier.  The
>>>>>>>> override of the keyword \"auto\" in xen/compiler.h is to give it it's
>>>>>>>> C23 behaviour of type inference."
>>>>>>>>
>>>>>>>> ?
>>>>>>> Seems good to me. Maybe this should be spelled out in ./CODING_STYLE as
>>>>>>> well, so that newcomers don't trip over this?
>>>>>> I'm not sure newcomers would look there, but in the absence of any better
>>>>>> place that's perhaps indeed where to mention this.
>>>>> How about this:
>>>>>
>>>>> diff --git a/CODING_STYLE b/CODING_STYLE
>>>>> index 7bf3848444ad..e33b9d1170cf 100644
>>>>> --- a/CODING_STYLE
>>>>> +++ b/CODING_STYLE
>>>>> @@ -129,6 +129,10 @@ Fixed width types should only be used when a fixed width quantity is
>>>>>  meant (which for example may be a value read from or to be written to a
>>>>>  register).
>>>>>
>>>>> +Macros which otherwise would use "typeof(arg) newarg =" to avoid double
>>>>> +evaluation of side effects should use "auto newarg =" per it's C23 behaviour,
>>>>> +to also avoid double textural expansion.
>>>>> +
>>>>>  Especially with pointer types, whenever the pointed to object is not
>>>>>  (supposed to be) modified, qualify the pointed to type with "const".
>>>> That doesn't focus on the pitfall though, in that people shouldn't be using
>>>> the "auto" keyword (except in said cases).
>>>
>>> /sigh, this is why noone does patches to CODING_STYLE.
>>>
>>> If you don't like the wording, propose some wording that you do like.
>>>
>>> Or I will commit the patch without this hunk, because I'm not going to
>>> get drawn into the cycle of blind guessing that every change to
>>> CODING_STYLE seems to get caught in.
>>
>> I don't care about the wording; what I do care about is to get the caveat
>> across. Maybe:
>>
>> '"auto" isn't used in its traditional sense, but rather with its C23 meaning.
>>  Such uses are intended to be limited to macro-local variables.'
> 
> Why limiting to macros?

Because, if I understood Andrew correctly, the specific goal is to help limit
what macros expand to.

Jan

Re: [PATCH v2] xen: Use auto as per C23

[Frediano Ziglio]

On Thu, Aug 14, 2025 at 11:25 PM Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
>
> In macros it is common to declare local variables using typeof(param) in order
> to ensure that side effects are only evaluated once.  A consequence of this is
> double textural expansion of the parameter, which can get out of hand very
> quickly with nested macros.
>
> In C23, the auto keyword has been repurposed to perform type inference.
>
> A GCC extension, __auto_type, is now avaialble in the new toolchain baseline
> and avoids the double textural expansion.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Anthony PERARD <anthony.perard@vates.tech>
> CC: Michal Orzel <michal.orzel@amd.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Julien Grall <julien@xen.org>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Roberto Bagnara <roberto.bagnara@bugseng.com>
> CC: Nicola Vetrini <nicola.vetrini@bugseng.com>
> CC: consulting@bugseng.com <consulting@bugseng.com>
>
> The resulting build is identical.
>
> v2:
>  * Use auto directly
>  * Eclair configuration
>
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1985289434
> ---
>  automation/eclair_analysis/ECLAIR/toolchain.ecl | 11 +++++++++--
>  docs/misra/C-language-toolchain.rst             |  2 ++
>  xen/include/xen/compiler.h                      | 14 ++++++++++++++
>  xen/include/xen/macros.h                        | 14 +++++++-------
>  4 files changed, 32 insertions(+), 9 deletions(-)
>
> diff --git a/automation/eclair_analysis/ECLAIR/toolchain.ecl b/automation/eclair_analysis/ECLAIR/toolchain.ecl
> index 842f8377e561..125f99a06583 100644
> --- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
> +++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
> @@ -15,6 +15,7 @@
>      __alignof__, __alignof: see Sections \"6.48 Alternate Keywords\" and \"6.44 Determining the Alignment of Functions, Types or Variables\" of "GCC_MANUAL".
>      asm, __asm__: see Sections \"6.48 Alternate Keywords\" and \"6.47 How to Use Inline Assembly Language in C Code\" of "GCC_MANUAL".
>      __attribute__: see Section \"6.39 Attribute Syntax\" of "GCC_MANUAL".
> +    __auto_type: see Section \"6.7 Referring to a Type with typeof\" of "GCC_MANUAL".
>      __builtin_offsetof: see Section \"6.53 Support for offsetof\" of "GCC_MANUAL".
>      __builtin_types_compatible_p: see Section \"6.59 Other Built-in Functions Provided by GCC\" of "GCC_MANUAL".
>      __builtin_va_arg: non-documented GCC extension.
> @@ -26,6 +27,7 @@
>  -name_selector+={alignof, "^(__alignof__|__alignof)$"}
>  -name_selector+={asm, "^(__asm__|asm)$"}
>  -name_selector+={attribute, "^__attribute__$"}
> +-name_selector+={auto_type, "^__auto_type$"}
>  -name_selector+={builtin_offsetof, "^__builtin_offsetof$"}
>  -name_selector+={builtin_types_p, "^__builtin_types_compatible_p$"}
>  -name_selector+={builtin_va_arg, "^__builtin_va_arg$"}
> @@ -39,6 +41,7 @@
>  "alignof||
>  asm||
>  attribute||
> +auto_type||
>  builtin_offsetof||
>  builtin_types_p||
>  builtin_va_arg||
> @@ -114,6 +117,7 @@ volatile"
>  -doc_end
>
>  -doc_begin="
> +    ext_auto_type: see Section \"6.7 Referring to a Type with typeof\" of "GCC_MANUAL".
>      ext_c_missing_varargs_arg: see Section \"6.21 Macros with a Variable Number of Arguments\" of "GCC_MANUAL".
>      ext_enum_value_not_int: non-documented GCC extension.
>      ext_flexible_array_in_array: see Section \"6.18 Arrays of Length Zero\" of "GCC_MANUAL".
> @@ -126,6 +130,7 @@ volatile"
>      ext_return_has_void_expr: see the documentation for -Wreturn-type in Section \"3.8 Options to Request or Suppress Warnings\" of "GCC_MANUAL".
>      ext_sizeof_alignof_void_type: see Section \"6.24 Arithmetic on void- and Function-Pointers\" of "GCC_MANUAL".
>  "
> +-name_selector+={ext_auto_type, "^ext_auto_type$"}
>  -name_selector+={ext_c_missing_varargs_arg, "^ext_c_missing_varargs_arg$"}
>  -name_selector+={ext_enum_value_not_int, "^ext_enum_value_not_int$"}
>  -name_selector+={ext_flexible_array_in_array, "^ext_flexible_array_in_array$"}
> @@ -139,7 +144,8 @@ volatile"
>  -name_selector+={ext_sizeof_alignof_void_type, "^ext_sizeof_alignof_void_type$"}
>
>  -config=STD.diag,behavior+={c99,GCC_ARM64,
> -"ext_c_missing_varargs_arg||
> +"ext_auto_type||
> +ext_c_missing_varargs_arg||
>  ext_forward_ref_enum_def||
>  ext_gnu_array_range||
>  ext_gnu_statement_expr_macro||
> @@ -149,7 +155,8 @@ ext_return_has_void_expr||
>  ext_sizeof_alignof_void_type"
>  }
>  -config=STD.diag,behavior+={c99,GCC_X86_64,
> -"ext_c_missing_varargs_arg||
> +"ext_auto_type||
> +ext_c_missing_varargs_arg||
>  ext_enum_value_not_int||
>  ext_flexible_array_in_array||
>  ext_flexible_array_in_struct||
> diff --git a/docs/misra/C-language-toolchain.rst b/docs/misra/C-language-toolchain.rst
> index cb81f5c09872..635936004554 100644
> --- a/docs/misra/C-language-toolchain.rst
> +++ b/docs/misra/C-language-toolchain.rst
> @@ -94,6 +94,8 @@ The table columns are as follows:
>            see Sections "6.48 Alternate Keywords" and "6.44 Determining the Alignment of Functions, Types or Variables" of GCC_MANUAL.
>         __attribute__:
>            see Section "6.39 Attribute Syntax" of GCC_MANUAL.
> +       __auto_type:
> +          see Section "6.7 Referring to a Type with typeof" of GCC_MANUAL.
>         __builtin_types_compatible_p:
>            see Section "6.59 Other Built-in Functions Provided by GCC" of GCC_MANUAL.
>         __builtin_va_arg:
> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
> index 88bf26bc5109..38ef5d82ad95 100644
> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -64,6 +64,20 @@
>  # define asm_inline asm
>  #endif
>
> +/*
> + * In C23, the auto keyword has been repurposed to perform type inference.
> + *
> + * This behaviour is available via the __auto_type extension in supported
> + * toolchains.
> + *
> + * https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Auto-Type.html
> + * https://clang.llvm.org/docs/LanguageExtensions.html#auto-type
> + */
> +#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L
> +/* SAF-3-safe MISRA C Rule 20.4: Giving the keyword it's C23 meaning. */
> +#define auto __auto_type
> +#endif
> +
>  /*
>   * Add the pseudo keyword 'fallthrough' so case statement blocks
>   * must end with any of these keywords:
> diff --git a/xen/include/xen/macros.h b/xen/include/xen/macros.h
> index f9ccde86fb23..ceca2e4a1bf1 100644
> --- a/xen/include/xen/macros.h
> +++ b/xen/include/xen/macros.h
> @@ -63,18 +63,18 @@
>  /* Hide a value from the optimiser. */
>  #define HIDE(x)                                 \
>      ({                                          \
> -        typeof(x) _x = (x);                     \
> +        auto _x = (x);                          \
>          asm volatile ( "" : "+r" (_x) );        \
>          _x;                                     \
>      })
>
>  #define ABS(x) ({                              \
> -    typeof(x) x_ = (x);                        \
> +    auto x_ = (x);                             \
>      (x_ < 0) ? -x_ : x_;                       \
>  })
>
>  #define SWAP(a, b) \
> -   do { typeof(a) t_ = (a); (a) = (b); (b) = t_; } while ( 0 )
> +   do { auto t_ = (a); (a) = (b); (b) = t_; } while ( 0 )
>
>  #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]) + __must_be_array(x))
>
> @@ -102,15 +102,15 @@
>   */
>  #define min(x, y)                               \
>      ({                                          \
> -        const typeof(x) _x = (x);               \
> -        const typeof(y) _y = (y);               \
> +        const auto _x = (x);                    \
> +        const auto _y = (y);                    \
>          (void)(&_x == &_y); /* typecheck */     \
>          _x < _y ? _x : _y;                      \
>      })
>  #define max(x, y)                               \
>      ({                                          \
> -        const typeof(x) _x = (x);               \
> -        const typeof(y) _y = (y);               \
> +        const auto _x = (x);                    \
> +        const auto _y = (y);                    \
>          (void)(&_x == &_y); /* typecheck */     \
>          _x > _y ? _x : _y;                      \
>      })
>
> base-commit: b2c0dc44b37516b758c38de04c61ad295ac0dff2

Thanks for the change, nice to have it.

Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>

Frediano