On 7/29/25 16:26, Jan Beulich wrote:
> On 29.07.2025 15:16, Nicola Vetrini wrote:
>> On 2025-07-29 15:09, Jan Beulich wrote:
>>> On 29.07.2025 15:02, Nicola Vetrini wrote:
>>>> On 2025-07-29 14:39, Jan Beulich wrote:
>>>>> On 29.07.2025 14:21, Dmytro Prokopchuk1 wrote:
>>>>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>>>> @@ -367,6 +367,13 @@ constant expressions are required.\""
>>>>>> }
>>>>>> -doc_end
>>>>>>
>>>>>> +-doc_begin="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."
>>>>>> +-config=MC3A2.R11.1,casts+={safe,
>>>>>> +
>>>>>> "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))&&all_param(1,
>>>>>> pointer(builtin(void)))))))&&from(expr(skip(!syntactic(),
>>>>>> + ref(property(noreturn)))))"}
>>>>>> +-doc_end
>>>>>
>>>>> As I understand it, this is about any function, not just void (void
>>>>> *)
>>>>> ones.
>>>>> Hence throughout anything textual in this patch, may I ask that this
>>>>> be
>>>>> made
>>>>> explicit by inserting e.g. "e.g." everywhere?
>>>>
>>>> Technically yes, in practice other implicit function pointer
>>>> conversions
>>>> would be caught by -Wincompatible-pointer-types and similar flags so
>>>> they don't even come into play. However I agree that adding that is
>>>> clearer.
>>>
>>> Perhaps a misunderstanding: With "any" I meant any which has a noreturn
>>> attribute, when converted to one with otherwise the same signature. But
>>> irrespective of the particular return type or parameter types (i.e.
>>> specifically not just void (void *) ones).
>>
>> Ah, sorry, I misunderstood. We check the destination type of the
>> conversion with
>> "to(type(pointer(inner(return(builtin(void))&&all_param(1,
>> pointer(builtin(void)))))))". In principle it could be avoided but I
>> think that at the moment it's ok as it is, then if it needs to be
>> extended when more cases emerge I can do that.
>
> Oh, then my comment to Dmytro (still in context above) was wrong. But
> why would we limit things as much? For noreturn functions a return type
> of other than void is surely not to be expected, so that part is fine.
> Yet any kinds of parameters would want to be permitted.
>
> Jan
As the Eclair tries to check the exact function prototype, deviation
wording is acceptable, per my understanding.
Regarding the patch subject, I may to change it to this:
"misra: allow discarding 'noreturn' during function pointer conversions".
Dmytro
