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

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


  • To: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • From: Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>
  • Date: Mon, 28 Jul 2025 18:58: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=4k4DttnZ5TvZJEYl6WdJafyMQt9GDiEZ812ADnOJnhI=; b=IG3OGP0ocBtQ3FjAD8/SCYwFhUPPRNURfRG91EoXA/YYk/id9ZNz4quRehOnPrhQ61lecIaq7+c8HG9knM2X+2PpTeUnhVoH5aSAFVQzzTCfM6apeS6CZAxrOcT7QENaf3F4+AqvyP6nZIOW6/MnW8Ilg2NSXkixhC5Bj9Jx2FFj/Uzrae7ssv8WBQW9JmsRR7wJTAl915LeQwvetziThivyTt//qBgfZVLo+Qr+LKqYbvwG821zO3FlTbjhDBpHdre7rEeA9cNqHq0suDEfu2R9EFwqceivjcK4po1RJrgwT9mFHeQNqMRGcvtvYGu34Jr0vXvAOzr/OmDEeG+Hiw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NRecdes8axyy9x+HrjYuGZKMyAQFYuHwJcU83rhDIVhT3XZm4KAZcNP+s/9ay5QXJEvUSKq7xgJXqKyaEAwncfVbADsb7UkAtWxzHOY+NwxM3Q0eQGRD/U6gxWnJZFRYSI7Xs6brbaCdITADZo53Azx1hJN6BIROnBMgSdeIf5Kbsvwj4IiX1NX68EFDPf2gQ8Usu56/5UPnopKxnGDnPfhd62gS/KH3StsFoYhhh2mySj2rJxSB1vfZ7OpK/jyaIxNlRaDykB1/PkbgEkVY8gM1e+xrcru6bx/rxkSneWgbelUKm/ECBzsqxUCoMH59Fj951e7DA76sZ5BLYsR+CA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, "consulting@xxxxxxxxxxx" <consulting@xxxxxxxxxxx>, 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>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Mon, 28 Jul 2025 18:58:41 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHb/zTS/PoTkNo+DkioPyw1aNE6A7RHTViAgAAOt4CAAHPhAIAABWuAgAAPboA=
  • Thread-topic: [PATCH] misra: deviate explicit cast for Rule 11.1


On 7/28/25 21:03, Dmytro Prokopchuk wrote:
> 
> 
> On 7/28/25 20:43, Nicola Vetrini wrote:
>> On 2025-07-28 12:49, Andrew Cooper wrote:
>>> On 28/07/2025 10:56 am, 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.
>>>
>>> I agree.  This code is *far* safer in practice without the cast, than
>>> with it.
>>>
>>>> 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.
>>>
>>> I guess that Eclair cannot know what an arbitrary attribute does and
>>> whether it impacts the ABI, but it would be lovely if Eclair could be
>>> told "noreturn is a safe attribute to differ on"?
>>>
>>
>> I'm convinced it can do that. Perhaps something like
>>
>> -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)))))"}
>>
>> which is a mess but decodes to that, more or less.
>>
>> I haven't tested it yet, though, but on a toy example [1] it works.
>>
>> [1]
>> void __attribute__((noreturn)) f(void *p) {
>>    __builtin_abort();
>> }
>>
>> void g(int x, void (*fp)(void *p)) {
>>    if (x < 3) {
>>      f((void*)x);
>>    }
>> }
>>
>> int main(int argc, char **argv) {
>>    g(argc, f);
>>    return 0;
>> }
>>
> Thanks, Nicola.
> I will check this.
> 
> Dmytro.
It works.
The violation "non-compliant cast: implicit cast from `void(*)(void*)' 
to `void(*)(void*)'" is gone.

Dmytro


 


Rackspace

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