On Fri, Aug 15, 2025 at 1:28 PM Jan Beulich <jbeul...@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.coop...@citrix.com> > >>>>>>> Reviewed-by: Nicola Vetrini <nicola.vetr...@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
