[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: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
- Date: Tue, 29 Jul 2025 13:03:28 +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=1753787009; 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=CH3bbWy2R9ZAzZjDVTUUaA2Mv3rrlPVf8rn0MNUUQSc=; b=JfqUHtbthcN+ruGYMemamUCl7zqz08BwhUe7UyP+76/z3WdMt/9uHq1u6NqRhP+6/FDq QNdGy4v9yMc4g+K5UQ0sXgNzyyD6aezHzsZKLO+vmhBXjspCNyF22+8IxAP5QaRPvn8d8 xV1wQTxt/PNFu4pw6R0vYh2hy7QdwvV411JmreIcG9pFW/y5Zw8XDnGVjAEObPVGvSpT1 c4McmkRnnVyJrKWZwHtgRw9lU1NatjGsiZRvrTACJ/jZG83/nFOZqUDmKppKTSLh3mPLI kFLspGLrqRWZpJz8O0LbWdGNjWPSqxOkl8PMa8Ff+wwTpzWDyrO89zDQ6PwbHjku9wtws bFOPzFeVW+jC76Lxx5Ief7fi0igNpFd8vN7Zv5eBnXbx7VfUxm8C3BYvfVSzITnCXfwMA czVQIc/NuxqRYtszZkyqV05sBLp8SBo1qFIkcXdqqjieWdsZnbb0mwKdjYGWk0HWppWvG DjSq8v0OPU//vBlqoeTIrtUTzKNpOT9BntxmhEDnQL0noFx9y8j+URYhmct2GmGhILxCJ ZlELdNJMjF9kUlm7wKyEWbParwAhQ4lv5obtErhK2Inf+UsgcBEjGoTrHoGgT6DdeVsLB 6ceOMejlQwaxnAgH+vL/2DkuEVmiAd1e5yv4rxJtWBt2VsIIjesY1d8LIQvem9o=
- Arc-seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1753787009; b=RrJL9NuT2NPtPqU3kotySFpAdi7pVbw1WwiK/CkwEieHirrqZ//nmRJrTIFZL1NhSyEm qsqxPpzluVDq6wXRnAbQ96u00U+x7qwGABEwtFLWMdxFQq1B4XVEg+9HaSuYOBOgYrcwT j54PS6bGdMzNg6J2EmHOtBxUkm58jpWLmkV8hdL7BXyTfnGgcPlsADxE8q2rGT2i5xGCe rtEtmRGQ3b5Rfs+pqISaIqE2IATmo0fxce93MgNSieAWeHDQKuWR+t739rkJItAzUEjVO Qt4CU1bFqyUMEEMHOs9U9Yjk+0kgFtMHPaDrXXTf8pPqdLwKL53FZySPsKGqWrw/lZ9H0 8q5eLXLTZJpR4zwTGDQW5KNqw5HbrRM9E2BpLKycOEe+8n6II1lVa5j9ziUO2Q4LxJzIf Qw1LuMuY6GHZop82eHpFwQHVpZ4YDW33NEh5KpAmA7H2wlm9QWpEKo4Ry+0T4yQlLClOJ WGqIWGFeV/5th0TBzVuB4x7MnNqeyN7KCH9ir+/VMaAtyUQvZ5qT9xZd7JVv48D0pOL3p Kc82Ioma1QFUFHHHuciAlRD5VTlo+/2h4lbqvuPNK+8z+r8BatjTXpIvRU3HXjQKHFlqT gPs/0t9KUDYRB50eA3PdcwozqBBG9FxsWuSvrEeVq/y3zdW8HTm28MtXusD6E1k=
- Authentication-results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
- Cc: 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, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>
- Delivery-date: Tue, 29 Jul 2025 11:11:42 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 2025-07-29 09:26, Jan Beulich wrote:
On 28.07.2025 21:17, Nicola Vetrini wrote:
On 2025-07-28 20:58, Dmytro Prokopchuk1 wrote:
It works.
The violation "non-compliant cast: implicit cast from
`void(*)(void*)'
to `void(*)(void*)'" is gone.
Great. Now what would be really useful is a way to abstract this more
nicely (I was able to write this only by looking at the AST). However
noreturn is probably about the only attribute that has a repercussion
on
the decl and is safe to cast away, unless I'm mistaken.
Not sure what you mean by "repercussion" here, and hence my remark may
be
entirely meaningless, but: const and pure are also examples of
attributes which are safe to cast away, aiui. In fact, given the sheer
number of attributes, I would be surprised if there weren't more.
Not all attributes influence compatibility of declarations. noreturn is
a bit special in the sense that gcc and clang don't quite agree on the
semantics of its various forms, where we follow clang's perspective. See
https://github.com/llvm/llvm-project/issues/113511 for instance, in
particular
So I think the only way in which Clang's behavior is diverging from
GCC's here is that we don't support an implicit conversion between
pointer-to-function and pointer-to-noreturn function. This should
presumably behave somewhat like the implicit conversion between pointer
to-function and pointer-to-noexcept-function except that it can
apparently be performed implicitly in either direction.
But in any case my remark was more about the future than current plans,
so there should be no bug here.
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
|
