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

[Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>]

On 10/13/26 11:08, Jan Beulich wrote:
> 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?

To be reworded like:

The conversion from a noreturn function pointer to a function pointer
with noreturn omitted but an otherwise compatible signature does not
alter the calling convention. 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 that all
of the possible callees are noreturn, or it may leave the code in
place. Xen's behavior is the same in either case. Code left in place
is a tolerated 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.)

I will spell void* as '(void *)'.

> 
>> +       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.

And to be reworded like above:

Conversions from a noreturn function pointer to a function pointer with 
noreturn omitted but an otherwise compatible signature are permitted.

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

Dmytro.