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

[Jan Beulich <jbeulich@xxxxxxxx>]

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