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
