[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] misra: deviate explicit cast for Rule 11.1


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>
  • Date: Mon, 28 Jul 2025 13:09:27 +0000
  • Accept-language: en-US, uk-UA, ru-RU
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tjKe6X+eYPguSrbqeM/C7uwAdBKE62l93TuD7AKcLE0=; b=D1dncpoIDsydi1WfzVFAuWnwdG7l0piVFXLNI9qNnR7p1S6ktefq3pP7wi/D17ibn1hWgIYCXVeTja2qsKNisffuJGTpsqpOMaioydqzA1Wh2Pfw9oMLZY3L8G83bvtjcjg01IVlcKYFACeaEY6iuw/tChJST1mWB8Mq/ynF7pq6KY6HOyxzrwhzuXdBGRZToyEp3mt3W9k9Y7Yks+B0PBxkjlsEjEr56pO3mMDZa9jUFHwlCWK1QqIykfSYETEpp2/vfERQGLrydxu4eh5ZedzEKJeLOXZJKie0B/5C+uHcXUsd624a1tLp6bvCIJ2KbKaFM5zcghBVuj8iIzQfyA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=myflVmUUPZ4zGNeF8JF4RnqNqvjaq707oZx+42g54FcXLzVRBi3bfYvdiYp9c/ZirW6gwfkASQBso7OCsLiC+eJCZIwC+bCImlL8YzUvMQtT/Dj4vdpJdrcI7fpbudqLCGhd3JwY4+T0knRio8QbAjhseAb/6+7mieZsGh2kmrdR322tGxmslxASwdPlvkLCwiXXF4I4kOLchtjFHMafhvU/rMBhAqJjVmfQPaEqo/qi6LN0rFz3RPJvKlUg14A0l4IF2wgD4Rnn7lrKRm6LqrA9+8YZ38w7Ab/Q3KIQIp/ukzxUE11SjEweIcxdkLpTMQoEfaZnM7qz5BHFmetsYQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "consulting@xxxxxxxxxxx" <consulting@xxxxxxxxxxx>
  • Delivery-date: Mon, 28 Jul 2025 13:09:32 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHb/zTS/PoTkNo+DkioPyw1aNE6A7RHTViAgAA17gA=
  • Thread-topic: [PATCH] misra: deviate explicit cast for Rule 11.1


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?

Dmytro



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.