[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] misra: deviate explicit cast for Rule 11.1
On 28.07.2025 15:09, Dmytro Prokopchuk1 wrote: > > > On 7/28/25 12:56, Jan Beulich wrote: >> On 27.07.2025 22:27, Dmytro Prokopchuk1 wrote: >>> Explicitly cast 'halt_this_cpu' when passing it >>> to 'smp_call_function' to match the required >>> function pointer type '(void (*)(void *info))'. >>> >>> Document and justify a MISRA C R11.1 deviation >>> (explicit cast). >>> >>> Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@xxxxxxxx> >> >> All you talk about is the rule that you violate by adding a cast. But what is >> the problem you're actually trying to resolve by adding a cast? >> >>> --- a/xen/arch/arm/shutdown.c >>> +++ b/xen/arch/arm/shutdown.c >>> @@ -25,7 +25,8 @@ void machine_halt(void) >>> watchdog_disable(); >>> console_start_sync(); >>> local_irq_enable(); >>> - smp_call_function(halt_this_cpu, NULL, 0); >>> + /* SAF-15-safe */ >>> + smp_call_function((void (*)(void *))halt_this_cpu, NULL, 0); >> >> Now this is the kind of cast that is very dangerous. The function's signature >> changing will go entirely unnoticed (by the compiler) with such a cast in >> place. >> >> If Misra / Eclair are unhappy about such an extra (benign here) attribute, >> I'd >> be interested to know what their suggestion is to deal with the situation >> without making the code worse (as in: more risky). I first thought about >> having >> a new helper function that then simply chains to halt_this_cpu(), yet that >> would result in a function which can't return, but has no noreturn attribute. >> >> Jan > > Yes, Misra doesn't like cast. > > Initially Misra reported about non-compliant implicit cast due to > 'noreturn' attribute: > smp_call_function(halt_this_cpu, NULL, 0); > > I thought that in this case explicit cast is better, telling compiler > exact type. > But, Misra reported about non-compliant c-style (explicit) cast. > So, I decided to deviate explicit cast. > > I tried to write wrapper function to resolve this. > Example: > static void halt_this_cpu_2(void *arg) > { > halt_this_cpu(arg); > } > void machine_halt(void) > { > ... > smp_call_function(halt_this_cpu_2, NULL, 0); > ... > > Unfortunately new R2.1 violation was observed. > "function definition `halt_this_cpu_2(void*)' (unit > `xen/arch/arm/shutdown.c' with target `xen/arch/arm/shutdown.o') will > never return" > > Maybe it's better to have such violation....instead of R11.1 > "non-compliant cast" > > > I can remove cast and re-write deviation justification. > Are you OK with that, Jan? I expect so, as a temporary measure. In the longer run I would hope Eclair can be adjusted to accept such cases without complaint. Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |