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

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


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • Date: Mon, 28 Jul 2025 19:43:50 +0200
  • Arc-authentication-results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
  • Arc-message-signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1753724631; h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To: References:Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=7BPNj/8AaJau18LtVlMhCLst9WTNlnZPcyFNXMfgwC0=; b=3XhAwbm8yEX+1iYOKvPwMNSo3TNp0bsKSIGyrjpaKIXvR9TA74yttrlSqTUdU/d3+Zj/ CyY/R6OMsIZvRKgjyWAHFOXxCiUGXqMe49XUI4m/bQ2ygG82ezzoTefP7RyatIPVA3/Hh klWRtsbkQ6JOdvp4KUAosXnprOewAFAFWOPxqkvyplUJsuV6Br+zNsG09HYTW4chwvoNA x39kE9nT7F8eU2Fq6OC9hYM0ROQFkQYQdbi8f4XrcEMoY50PO+YCWf7allVYcOdkOrmpN p3TOWyr1BPloZCYcHlwyNj4Br5hvdPOhBz+iiUKrUAEbv+OXm0q25ugHLp6fm8OhmkVz+ JtRlLA/TFsJL/WmBFAEgLLVDG+Vpn0KFreg5e3PY6YMrK8lexoE3P0NBYqia8JFq7EOQp 9DZr7TP2NxAd+NJBtUSSxXsviK3QgZq1UNqq85kVDTSvPg5LjK0odoxXIyyp5CHLOuVO+ 0mQgsH/0bE5ZVuKM45FBST8HDng9PHIEXpAXnE+k4AVf7jeMcAdUwHuHBN1XB7QVycxzu jCfqLm9vApvdeHwSnopTbGWw6QlJ75QocSvJiPG7epmm1MHkdANMw3lTEc25h3GvTKguT WacyNBDmw/pb7GaeV/ux2ix3RbtUoC7rv3dAJ4jnvCsZllvI17g7HbfVumvCHro=
  • Arc-seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1753724631; b=aFemo4I8T/y33RxSgGCGXhxMed5JDCyast8hBF6VSMZtoINqWAjiFv+FmTK3fIWYYh/J xCsbE10X/Dr6ZSKdqdh5pm7VO8qXRCdFNgfGaTQbKvoZUkCI81Y5mGCcbhEXt4Ik/N/Rz w0KZNg+hvpP/+IGto16kvOkxIXjqC1IPyZJ3YW6lB3FaljfLWlbAb4GZm+y35YwHG2E3y tUV3Ym/3TV7orpufR+OMqkWAQLX4RT4AsEOtJQzb7kkmEsOLKcYPWTGxtGw+f5CybPFzS fwjCXJP1C76pD8ZWvjkmELmoARs1mnpIkfXYrw7z5CkGrYbbIUinCkXE36/G8njgJS9jk ZqKrvTDD0bap6gnhCjf0+j4rTslI09uLQlzsNBtGOtAFC4KJIYMAd52/P17KEYB5jtyUy eC6e68vAWVF35PHKb3gWoT74WQA2LDH/DQP1AcI3R2e+Fx8PPBY353ppOc7IQZR7AOPCM 6LtYief90svPu21gJoJ2qa16zSXTJZE6A/iZxcfnDr3Dpq6N3fSLPtK9GeFqmQaTJhtMV 9Z5+81CENEc4NbfiD2sUof6snMkikaKjzY7PU/uWwN33E1uYgo1FsmuL+j7xUMiOAk973 nryAIkKs/tohc1UbkZbiaaPMy3G+c+AkJp78Mh+iVwi6vVl2KMfLI80pyMvquBg=
  • Authentication-results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>, 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
  • Delivery-date: Mon, 28 Jul 2025 17:44:05 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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;
}

--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253



 


Rackspace

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