On 2025-07-29 12:52, Jan Beulich wrote:
On 29.07.2025 12:04, Dmytro Prokopchuk1 wrote:
On 7/29/25 11:04, Jan Beulich wrote:
On 29.07.2025 00:15, Dmytro Prokopchuk1 wrote:
ECLAIR reports a non-compliant cast due to the presence
of the 'noreturn' attribute in the callee function.
Which callee function? Which cast? Please be concrete. You don't need
to enumerate all case, but one specific example wants pointing at.
The issue occurs when casting a function pointer with
the 'noreturn' attribute (void noreturn (*)(void *))
to a general function pointer type (void (*)(void *)).
And again - why "casting"? As per ...
Configure ECLAIR to treat 'noreturn' attributes as safe
in this conversion.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopch...@epam.com>
---
Previous discussion thread:
https://patchew.org/Xen/181a03d5c7625d42c06cf9fa0cf48a9bc6825361.1753647875.git.dmytro._5fprokopch...@epam.com/
... there was no cast involved, iirc. We specifically rejected your
attempt to add a cast there. It's a conversion the compiler does,
aiui.
Yes, you are right.
Word "cast" is not appropriate there.
Below is updated text:
misra: allow 'noreturn' as safe for function pointer conversions
The conversion from a function pointer with the
'noreturn' attribute ('void noreturn (*)(void *)')
to a function pointer type ('void (*)(void *)'
causes type incompatibility according to
MISRA C Rule 11.1, which forbids conversions
between incompatible function pointer types.
The violation occurs at the call site
smp_call_function(halt_this_cpu, NULL, 0);
where 'halt_this_cpu' with type 'void noreturn (*)(void *)'
is passed to 'smp_call_function' expecting a function
pointer of type 'void (*)(void *)'.
The 'noreturn' attribute does not change the function
calling convention or parameter handling at runtime,
making the conversion safe.
Up to here things read much better now, thanks. Just one more request:
Please make better use of the 72 (or maybe even 75) characters that are
permitted per line.
Configure ECLAIR to treat 'noreturn' attributes as safe.
Configure ECLAIR to treat implicit casts that lose the "noreturn"
attribute on a function void (*fp)(void*) as safe. This is because the
deviation actually just deviates void noreturn (*fp)(void*) -> void
(*fp)(void*)
This one is still way to imprecise, though. And I hope it's only this
description, not also the Eclair configuration item that's overly lax.
Jan
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
