Re: [PATCH] x86/shim: adjust for Misra C:2012 rule 20.12

[Nicola Vetrini <nicola.vetrini@bugseng.com>]

On 2026-05-13 18:30, Andrew Cooper wrote:
> On 13/05/2026 4:52 pm, Jan Beulich wrote:
>> ... ("A macro parameter used as an operand to the `#' or `##' 
>> operators,
>> which is itself subject to further macro replacement, shall only be 
>> used
>> as an operand to these operators"). Move the HVM_PARAM_ prefixes into 
>> the
>> macro body, to use ## on the 2nd use (each) of the macro parameter.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> I understand that this "absorbing" of prefixes isn't liked by some 
>> people,
>> so I'm all ears towards alternative suggestions.
>> 
>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/14354119193
>> (also covering the 17.5 patch)
> 
> Yeah, I'm a firm -1 to absorbing the prefixes.  This is simple
> obfuscation just to hide it from Eclair's eyes.
> 
> The ARM folks fixed this by using a SAF-6 annotation.  e.g. 
> 195d754170891
> 
> Although honestly, the more I think about this, the more I think we
> should just globally deviate.  I don't consider the concept having a
> well-named constant be used both as a value and a string a confusing 
> thing.
> 

There are already special cases for R20.12 also for things like 
GENERATE_CASE

-doc_begin="The helper macro GENERATE_CASE may use a macro parameter for 
ordinary
expansion and token pasting to improve readability. Only instances where 
this
leads to a violation of the Rule are deviated."
-file_tag+={deliberate_generate_case, "^xen/arch/arm/vcpreg\\.c$"}
-config=MC3A2.R20.12,macros+={deliberate, 
"name(GENERATE_CASE)&&loc(file(deliberate_generate_case))"}
-doc_end

which fits this macro perfectly. The more general question is whether we 
want to whitelist certain macros uniformely, or in general Xen 
developers want to use that pattern, because that conversation has two 
very different outcomes: one is the disabling of the rule, though there 
is an associated unspecified behaviour. Us.B 25 for C99 to be precise: 
The order in which # and ## operations are evaluated during macro 
substitution (6.10.3.2, 6.10.3.3). The other possible outcome is 
deciding that the allowed cases, which should be very few (and indeed 
they are currently) should use a single deviation pattern to be handled 
uniformely.

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