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

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

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.
> > 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
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253