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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.10.2026 09:56, Dmytro Prokopchuk1 wrote:
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -392,10 +392,12 @@ Deviations related to MISRA C:2012 Rules:
>       - Tagged as `safe` for ECLAIR.
>  
>     * - R11.1
> -     - The conversion from 'void noreturn (*)(...)' to 'void (*)(...)' is 
> safe
> -       because the semantics of the 'noreturn' attribute do not alter the 
> calling
> -       convention or behavior of the resulting code, parameters handling 
> remain
> -       consistent.
> +     - The conversion from a noreturn function pointer to a function pointer
> +       with a compatible signature does not alter the calling convention.

"... with noreturn omitted but an otherwise compatible signature ..."

> +       The callee does not return, so code following a call through the
> +       resulting pointer is unreachable. The compiler may delete that
> +       unreachable code when it can see the noreturn callee, or it may

"... when it can see that all of the possible callees are noreturn, ..."

> +       leave the code in place. Xen's behavior is the same in either case.
>       - Tagged as `safe` for ECLAIR.

While kind of implicit, should it perhaps be made explicit that we tolerate
(deviate) such a violation of rule 2.1?

> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -435,9 +435,10 @@ maintainers if you want to suggest a change.
>         and any other type
>       - All conversions to integer types are permitted if the destination
>         type has enough bits to hold the entire value. Conversions to bool
> -       and void* are permitted. Conversions from 'void noreturn (*)(...)'
> -       to 'void (*)(...)' are permitted. Conversions from [unsigned] long
> -       or '(void *)' to a function pointer are permitted.
> +       and void* are permitted. Conversions from a noreturn function pointer

Nit: Take the opportunity and convert the badly formatted "void*" to match
the formatting in the last sentence? (It's not quite clear to me though
why that has parentheses; it would seem to me that just the quotes [and
the separating blank] ought to be sufficient. My main point here obviously
is that all spellings of the same thing would better be identical.)

> +       to a function pointer with a compatible signature are permitted.

Like above, it is imo important to state that the difference between both
pointers should be _only_ the "noreturn". That's lost here, just like it's
lost in deviations.rst.

Jan

> +       Conversions from [unsigned] long or '(void *)' to a function pointer
> +       are permitted.
>         Example::
>  
>             unsigned long func_addr = (unsigned long)&some_function;