Re: [PATCH v3] misra: allow discarding 'noreturn' during function pointer conversions

[Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>]

On 7/31/25 10:20, Jan Beulich wrote:
> On 30.07.2025 23:47, Dmytro Prokopchuk1 wrote:
>> --- a/docs/misra/deviations.rst
>> +++ b/docs/misra/deviations.rst
>> @@ -342,6 +342,12 @@ Deviations related to MISRA C:2012 Rules:
>>          semantics that do not lead to unexpected behaviour.
>>        - Tagged as `safe` for ECLAIR.
>>   
>> +   * - R11.1
>> +     - The conversion from 'void noreturn (*)(void *)' to 'void (*)(void *)'
>> +       is safe because the semantics of the 'noreturn' attribute do not 
>> alter
>> +       the calling convention or behavior of the resulting code.
>> +     - Tagged as `safe` for ECLAIR.
> 
> As before, imo such a deviation should be generic, i.e. here independent
> of what parameters a function takes. If that can't be easily expressed
> to Eclair, then that wants stating as a justification for the
> deviations.ecl change to not fully cover the deviation we put in place.
> Having the textual deviation generic means later possible needs can be
> easily addressed by just a deviations.ecl change, without any adjustment
> to the deviations themselves.
> 
> Jan

Hi, Jan

Currently Eclair checks exact pointer type 'void (*)(void *)', as 
described in the configuration:

to(type(pointer(inner(return(builtin(void))&&all_param(1, 
pointer(builtin(void)))))))

Nicola wrote: "then if it needs to be extended when more cases emerge I 
can do that".

So, for clarification.

1. In the file "deviations.ecl" I leave exist description and config:
"The conversion from 'void noreturn (*)(void *)' to 'void (*)(void *)' 
is safe because the semantics of the 'noreturn' attribute do not alter 
the calling convention or behavior of the resulting code."

2. In the file "deviations.rst" I change the description to:
"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, parameter 
handling remain consistent."

3. In the file "rules.rst" I change the description to:
"Conversions from 'void noreturn (*)(...)' to 'void (*)(...)' are 
permitted."

It means that only "deviations.ecl" needs to be updated if a new 
deviation needs to be addressed.


Is it OK?

Dmytro