Re: [PATCH 4/5] x86/shadow: split a nested max() invocation

[Jan Beulich <jbeulich@xxxxxxxx>]

On 14.05.2026 07:08, Nicola Vetrini wrote:
> On 2026-05-13 13:46, Jan Beulich wrote:
>> Such nesting causes the inner instance to shadow the outer instance's
>> macro-local variables, thus violating Misra C:2012 rule 5.3 ("An
>> identifier declared in an inner scope shall not hide an identifier
>> declared in an outer scope"). Use an intermediate variable for the
>> inner invocation. No difference in generated code.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> Supposedly this case is deviated (rules.rst). Does that deviation not 
>> work
>> quite right? Actually, am I mis-reading deviations.ecl or is the
>> respective setting only covering the combination of min() and max(), 
>> but
>> not multiple use of the same macro? Furthermore, why would e.g.
>> min(max_t(), ...) need a deviation? Even more generally, aren't those
>> expressions too permissive?
> 
> Yeah, it does cover only mixing max(_t)?/min(_t)? because that was the 
> only pattern that emerged in the safety scope originally. the _t is not 
> there for mixing e.g. min(max_t(...), ...) but rather for 
> min_t(max_t(...), ...) and viceversa; could be split if you think it's 
> worth it.

Yes, I think they would better be split. We shouldn't deviate
max(min_t(), ...) and alike.

> These expressions are a tad broad, because it's way more 
> complicated to express the condition: "ignore overlapping only beetween 
> identifiers defined in the expansion of max/min when used together". 

I understand the "more complicated" aspect, but from an assessor's pov
being too broad (lax) in deviations might easily be a negative point.

> Perhaps it could be done, but then if you are already implicitly using 
> shadowing in those instances maybe that's not as serious a concern?
> 
> In any case, the patch looks ok to me, so
> 
> Reviewed-by: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>

Thanks, also for all the other reviews you did.

Jan