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

[Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>]

On 10/12/26 09: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 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

Hi Nicola, Jan,

Thank you for the review.

In the next version I will update the deviation text. The ECLAIR's
configuration stays unchanged.

BR, Dmytro