Re: [PATCH] automation/eclair: generalize the noreturn function-pointer deviation

[Jan Beulich <jbeulich@xxxxxxxx>]

On 09.10.2026 17:37, Nicola Vetrini wrote:
> On 2026-10-05 20:56, Dmytro Prokopchuk1 wrote:
>> The R11.1 safe cast only matched void noreturn (*)(void *). Accept any
>> noreturn function pointer converted to a compatible function pointer.
>> canonical() covers typeof destinations, and compatible_deep_unqualified
>> keeps the parameter and return types aligned.
>>
>> Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@xxxxxxxx>
>> ---
>>
>> This patch tries to cover both of these:
>>
>> 1. eclair: widen R11.1 noreturn cast deviation
>> https://patchew.org/Xen/c6632dd805a119aca54b9d1ae2eea68ef9c1334c.1790674358.git.dmytro._5Fprokopchuk1@xxxxxxxx/
>>
>> 2. Eclair: relax "noreturn" function-pointer conversion deviation
>> https://patchew.org/Xen/6d212d60-5c0b-4909-996d-5d6a4906b7e1@xxxxxxxx/4cca58b6-b555-4064-aa26-5204dc4b99cc@xxxxxxxx/
>>
>> Test CI pipeline:
>> https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2914802667
>>
>> The only one Rule11.1 violation remains, which is covered by this Jan's 
>> patch:
>> x86/kexec: address Misra rule 11.1 violation in machine_kexec_load()
>>
> 
> The change itself is fine, but the aspect I'm concerned with is the 
> following: if you have a function marked noreturn, the compiler is 
> entitled to
> essentially remove any code following it, so in principle this could be 
> the case also when invoking a function pointer (i.e. the compiler has no 
> obligation to retain code after a call to a function pointer that is 
> actually a noreturn function). While this in practice may not happen 
> often (e.g., the analysis done by a compiler is probably too shallow to 
> actually infer paths where the function pointer is only ever assigned to 
> noreturn functions when it is called), it is still not completely true 
> to say that the behavior is not altered by casting away noreturn.

With "behavior" here you mean that of the compiler? Because Xen's behavior
won't change if the code following such an indirect call isn't eliminated.
It will "just" be unreachable code then.

That said, ...

> I have 
> given in [1] my R-by to the previous form of this deviation, but I 
> realize that this aspect should be mentioned. This is of course 
> supported by testing and code coverage evidence that the behavior is 
> indeed the same, or a suitable guarantee from the compiler vendor that 
> the behavior never diverges.

... making this explicit in the patch and/or deviation description is of
course not going to hurt.

Jan