From: Jan Beulich <jbeulich@suse.com>
To: Nicola Vetrini <nicola.vetrini@bugseng.com>
Cc: "Dmytro Prokopchuk1" <dmytro_prokopchuk1@epam.com>,
"Doug Goldstein" <cardoe@cardoe.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Anthony PERARD" <anthony.perard@vates.tech>,
"Michal Orzel" <michal.orzel@amd.com>,
"Julien Grall" <julien@xen.org>,
"Roger Pau Monné" <roger.pau@citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH] misra/eclair: set 'noreturn' attribute as safe during cast
Date: Tue, 29 Jul 2025 14:00:28 +0200 [thread overview]
Message-ID: <0916bed8-fa87-4003-8aad-af3a6ff7ccfc@suse.com> (raw)
In-Reply-To: <7c1de6ab79993a96f8c2cf6ce4c6ddff@bugseng.com>
On 29.07.2025 12:55, Nicola Vetrini wrote:
> On 2025-07-29 12:52, Jan Beulich wrote:
>> On 29.07.2025 12:04, Dmytro Prokopchuk1 wrote:
>>>
>>>
>>> On 7/29/25 11:04, Jan Beulich wrote:
>>>> On 29.07.2025 00:15, Dmytro Prokopchuk1 wrote:
>>>>> ECLAIR reports a non-compliant cast due to the presence
>>>>> of the 'noreturn' attribute in the callee function.
>>>>
>>>> Which callee function? Which cast? Please be concrete. You don't need
>>>> to enumerate all case, but one specific example wants pointing at.
>>>>
>>>>> The issue occurs when casting a function pointer with
>>>>> the 'noreturn' attribute (void noreturn (*)(void *))
>>>>> to a general function pointer type (void (*)(void *)).
>>>>
>>>> And again - why "casting"? As per ...
>>>>
>>>>> Configure ECLAIR to treat 'noreturn' attributes as safe
>>>>> in this conversion.
>>>>>
>>>>> Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
>>>>> ---
>>>>> Previous discussion thread:
>>>>> https://patchew.org/Xen/181a03d5c7625d42c06cf9fa0cf48a9bc6825361.1753647875.git.dmytro._5Fprokopchuk1@epam.com/
>>>>
>>>> ... there was no cast involved, iirc. We specifically rejected your
>>>> attempt to add a cast there. It's a conversion the compiler does,
>>>> aiui.
>>>>
>>> Yes, you are right.
>>> Word "cast" is not appropriate there.
>>>
>>> Below is updated text:
>>>
>>> misra: allow 'noreturn' as safe for function pointer conversions
>>>
>>> The conversion from a function pointer with the
>>> 'noreturn' attribute ('void noreturn (*)(void *)')
>>> to a function pointer type ('void (*)(void *)'
>>> causes type incompatibility according to
>>> MISRA C Rule 11.1, which forbids conversions
>>> between incompatible function pointer types.
>>>
>>> The violation occurs at the call site
>>> smp_call_function(halt_this_cpu, NULL, 0);
>>> where 'halt_this_cpu' with type 'void noreturn (*)(void *)'
>>> is passed to 'smp_call_function' expecting a function
>>> pointer of type 'void (*)(void *)'.
>>>
>>> The 'noreturn' attribute does not change the function
>>> calling convention or parameter handling at runtime,
>>> making the conversion safe.
>>
>> Up to here things read much better now, thanks. Just one more request:
>> Please make better use of the 72 (or maybe even 75) characters that are
>> permitted per line.
>>
>>> Configure ECLAIR to treat 'noreturn' attributes as safe.
>
> Configure ECLAIR to treat implicit casts that lose the "noreturn"
> attribute on a function void (*fp)(void*) as safe. This is because the
> deviation actually just deviates void noreturn (*fp)(void*) -> void
> (*fp)(void*)
Thanks. Just one more nit: s/casts/conversions/.
Jan
prev parent reply other threads:[~2025-07-29 12:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-28 22:15 [PATCH] misra/eclair: set 'noreturn' attribute as safe during cast Dmytro Prokopchuk1
2025-07-29 8:04 ` Jan Beulich
2025-07-29 10:04 ` Dmytro Prokopchuk1
2025-07-29 10:52 ` Jan Beulich
2025-07-29 10:55 ` Nicola Vetrini
2025-07-29 12:00 ` Jan Beulich [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0916bed8-fa87-4003-8aad-af3a6ff7ccfc@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=cardoe@cardoe.com \
--cc=dmytro_prokopchuk1@epam.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=nicola.vetrini@bugseng.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.