Re: [PATCH] misra/eclair: set 'noreturn' attribute as safe during cast

[Jan Beulich <jbeulich@xxxxxxxx>]

On 29.07.2025 12:04, Dmytro Prokopchuk1 wrote:
> 
> 
> On 7/29/25 11:04, Jan Beulich wrote:
>> On 29.07.2025 00:15, Dmytro Prokopchuk1 wrote:
>>> ECLAIR reports a non-compliant cast due to the presence
>>> of the 'noreturn' attribute in the callee function.
>>
>> Which callee function? Which cast? Please be concrete. You don't need
>> to enumerate all case, but one specific example wants pointing at.
>>
>>> The issue occurs when casting a function pointer with
>>> the 'noreturn' attribute (void noreturn (*)(void *))
>>> to a general function pointer type (void (*)(void *)).
>>
>> And again - why "casting"? As per ...
>>
>>> Configure ECLAIR to treat 'noreturn' attributes as safe
>>> in this conversion.
>>>
>>> Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@xxxxxxxx>
>>> ---
>>> Previous discussion thread:
>>> https://patchew.org/Xen/181a03d5c7625d42c06cf9fa0cf48a9bc6825361.1753647875.git.dmytro._5Fprokopchuk1@xxxxxxxx/
>>
>> ... there was no cast involved, iirc. We specifically rejected your
>> attempt to add a cast there. It's a conversion the compiler does, aiui.
>>
> Yes, you are right.
> Word "cast" is not appropriate there.
> 
> Below is updated text:
> 
>      misra: allow 'noreturn' as safe for function pointer conversions
> 
>      The conversion from a function pointer with the
>      'noreturn' attribute ('void noreturn (*)(void *)')
>      to a function pointer type ('void (*)(void *)'
>      causes type incompatibility according to
>      MISRA C Rule 11.1, which forbids conversions
>      between incompatible function pointer types.
> 
>      The violation occurs at the call site
>          smp_call_function(halt_this_cpu, NULL, 0);
>      where 'halt_this_cpu' with type 'void noreturn (*)(void *)'
>      is passed to 'smp_call_function' expecting a function
>      pointer of type 'void (*)(void *)'.
> 
>      The 'noreturn' attribute does not change the function
>      calling convention or parameter handling at runtime,
>      making the conversion safe.

Up to here things read much better now, thanks. Just one more request:
Please make better use of the 72 (or maybe even 75) characters that are
permitted per line.

>      Configure ECLAIR to treat 'noreturn' attributes as safe.

This one is still way to imprecise, though. And I hope it's only this
description, not also the Eclair configuration item that's overly lax.

Jan