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

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

On 2026-10-13 14:37, Jan Beulich wrote:
> 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@epam.com>
>>>>> ---
>>>>> 
>>>>> 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@epam.com/
>>>>> 
>>>>> 2. Eclair: relax "noreturn" function-pointer conversion deviation
>>>>> https://patchew.org/Xen/6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com/4cca58b6-b555-4064-aa26-5204dc4b99cc@suse.com/
>>>>> 
>>>>> 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.
> 

For a direct function call the prototype would hopefully be visible, so 
it's easier to diagnose. For function pointers the prototype may not be 
visible, but a static analyzer can in principle do an over-approximation 
of all the possible function pointers that may be bound at that call 
site and derive their attributes from declaration(s). In any case, an 
argument for allowing the deviation may be that code coverage on tests 
shows that the compiler does the expected thing on the tested 
configuration: where code is expected not to be removed, it is indeed 
preserved and reached, and vice versa.

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