Re: [PATCH 3/4] Eclair: relax "noreturn" function-pointer conversion deviation

[Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>]

On 9/14/26 09:27, Jan Beulich wrote:
> On 12.09.2026 18:04, Nicola Vetrini wrote:
>> On 2026-09-03 13:44, Jan Beulich wrote:
>>> Like misra/rules.rst says, function arguments other than "void *" are okay
>>> as well.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>> ---
>>> I can't explain why this covers the violation in mce.c:mce_callbacks'es
>>> initializer, but not the one in mce.c:default_handler's.
>>
>> Possibly differing attributes (e.g. cf_check vs section attributes)? Just a 
>> guess that would need to be tested, though.
> 
> As long as its guesswork, it could end up being many (expensive) tries.
> 
>>> As a result of 6852334f8416 ("Arm/GIC: add noreturn in a few more
>>> places"), vgic_v2_lpi_to_pending() and vgic_v2_lpi_get_priority() (both
>>> returning non-void) would also need covering. (As said in a remark there,
>>> non-void together with noreturn is somewhat odd.)
>>
>> Indeed
>>
>>> Really before and after this change there's no checking that parameter and
>>> return types actually match. I have no clue how one would express such
>>> checks.
> 
> With this last sentence in mind ...
> 
>> The presence of a bitcast indicates that the two types do not match exactly. 
>> Typically function attributes are not relevant towards determining a type 
>> difference, but different compilers may model non-standard features 
>> differently (rightly so), in such a way that some make a difference in the 
>> AST, and others do not.
>>
>> To check for compatibility of function pointers I would try activating 
>> service STD.funptrcv, which essentially mirrors -Wincompatible-pointer-types:
>>
>> caution for rule STD.funptrcv: (rule) A pointer is used to call a function 
>> whose type is not compatible with the pointed-to type. (untagged)
>> p.c:8.8-8.8: Loc #1 [culprit: implicit cast converts from `void(*)(int)' to 
>> `__typeof__(@EXPR@)*' (that is `void(*)(void)')]
>>    qq = m;
>>         ^
>> p.c: In function ‘h’:
>> p.c:8:6: error: assignment to ‘void (*)(void)’ from incompatible pointer 
>> type ‘void (*)(int)’ [-Wincompatible-pointer-types]
>>      8 |   qq = m;
>>        |      ^
>> p.c:3:6: note: ‘m’ declared here
>>      3 | void m(int x);
>>        |      ^
> 
> ... - well, fine, but ...
> 
>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> @@ -391,11 +391,11 @@ constant expressions are required.\""
>>>   }
>>>   -doc_end
>>>
>>> --doc_begin="The conversion from 'void noreturn (*)(void *)' to 'void 
>>> (*)(void *)' is safe
>>> +-doc_begin="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."
>>>   -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)))))"}
>>> +  
>>> "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))))))&&from(expr(skip(!syntactic(),ref(property(noreturn)))))"
>>> +}
>>>   -doc_end
> 
> ... how would this be expressed here? Perhaps best if you would make an
> alternative patch?
> 
> Jan

Please, take a look:
https://patchew.org/Xen/d68c56607781bfa829766aed36eeb31f06080fbc.1791224638.git.dmytro._5Fprokopchuk1@xxxxxxxx/

BR, Dmytro.