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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 31.07.2025 18:48, Dmytro Prokopchuk1 wrote:
> 
> 
> 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?

Yes, with the patch description also suitably adjusted.

Jan