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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.10.2026 13:46, Nicola Vetrini wrote:
> On 2026-10-12 08:52, Jan Beulich wrote:
>> 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 was more worried about the other direction: code that is expected to 
> be executed by the developer that is instead removed by the compiler, 
> with (rightfully) no diagnostic. Clearly if code is not removed it would 
> be unreachable, but such that a static analysis tool or compiler will 
> likely not diagnose, precisely because the attribute is dropped, so 
> there may be missing diagnostics.

Hmm, interesting. The noreturn attribute isn't visible at call sites
anyway, so I don't quite see how that would be any more unexpected than
for a normal (direct) function call.

Jan