* [PATCH v4] misra: allow discarding 'noreturn' during conversions
@ 2025-08-01 10:48 Dmytro Prokopchuk1
2025-08-01 10:53 ` Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: Dmytro Prokopchuk1 @ 2025-08-01 10:48 UTC (permalink / raw)
To: xen-devel@lists.xenproject.org
Cc: Dmytro Prokopchuk1, Nicola Vetrini, Doug Goldstein,
Stefano Stabellini, Andrew Cooper, Anthony PERARD, Michal Orzel,
Jan Beulich, Julien Grall, Roger Pau Monné
The conversion from a function pointer with the 'noreturn' attribute
('void noreturn (*)(...)') to a function pointer type ('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 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.
Configure ECLAIR to treat implicit conversions that lose the "noreturn"
attribute on a function 'void (*)(void*)' as safe.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
---
Changes in v4:
- removed words "function pointer" in subject (to fit in 50 chars)
- wrote deviation description more generic
- adjusted commit message
- adjusted of line capacity
Link to v3:
https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg00009.html
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 7 +++++++
docs/misra/deviations.rst | 7 +++++++
docs/misra/rules.rst | 9 +++++----
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 483507e7b9..0e04681c4c 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -367,6 +367,13 @@ constant expressions are required.\""
}
-doc_end
+-doc_begin="The conversion from 'void noreturn (*)(void *)' to 'void (*)(void *)' is safe
+because the semantics of the 'noreturn' attribute do not alter the calling convention or behavior of the resulting code."
+-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)))))"}
+-doc_end
+
-doc_begin="The conversion from a pointer to an incomplete type to unsigned long does not lose any information, provided that the target type has enough bits to store it."
-config=MC3A2.R11.2,casts+={safe,
"from(type(any()))
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index e78179fcb8..38b536dfe4 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -342,6 +342,13 @@ Deviations related to MISRA C:2012 Rules:
semantics that do not lead to unexpected behaviour.
- Tagged as `safe` for ECLAIR.
+ * - R11.1
+ - The conversion from 'void noreturn (*)(...)' to 'void (*)(...)' is safe
+ because the semantics of the 'noreturn' attribute do not alter the calling
+ convention or behavior of the resulting code, parameters handling remain
+ consistent.
+ - Tagged as `safe` for ECLAIR.
+
* - R11.2
- The conversion from a pointer to an incomplete type to unsigned long
does not lose any information, provided that the target type has enough
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 3e014a6298..2b6f30e56d 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -400,11 +400,12 @@ maintainers if you want to suggest a change.
* - `Rule 11.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_01.c>`_
- Required
- - Conversions shall not be performed between a pointer to a
- function and any other type
+ - Conversions shall not be performed between a pointer to a function
+ and any other type
- All conversions to integer types are permitted if the destination
- type has enough bits to hold the entire value. Conversions to
- bool and void* are permitted.
+ type has enough bits to hold the entire value. Conversions to bool
+ and void* are permitted. Conversions from 'void noreturn (*)(...)'
+ to 'void (*)(...)' are permitted.
* - `Rule 11.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_02.c>`_
- Required
--
2.43.0
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH v4] misra: allow discarding 'noreturn' during conversions
2025-08-01 10:48 [PATCH v4] misra: allow discarding 'noreturn' during conversions Dmytro Prokopchuk1
@ 2025-08-01 10:53 ` Jan Beulich
2025-08-01 10:58 ` Nicola Vetrini
2025-08-01 11:22 ` Dmytro Prokopchuk1
0 siblings, 2 replies; 4+ messages in thread
From: Jan Beulich @ 2025-08-01 10:53 UTC (permalink / raw)
To: Dmytro Prokopchuk1
Cc: Nicola Vetrini, Doug Goldstein, Stefano Stabellini, Andrew Cooper,
Anthony PERARD, Michal Orzel, Julien Grall, Roger Pau Monné,
xen-devel@lists.xenproject.org
On 01.08.2025 12:48, Dmytro Prokopchuk1 wrote:
> The conversion from a function pointer with the 'noreturn' attribute
> ('void noreturn (*)(...)') to a function pointer type ('void (*)(...)'
> causes type incompatibility according to MISRA C Rule 11.1, which
> forbids conversions between incompatible function pointer types.
This wider deviation ...
> 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 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.
>
> Configure ECLAIR to treat implicit conversions that lose the "noreturn"
> attribute on a function 'void (*)(void*)' as safe.
... wants connecting to this more narrow Eclair configuration. That's what
I meant when I said "description also suitably adjusted". For example, the
last sentence above could start "For now, configure Eclair to just treat
...". Can adjust when committing, assuming an ack for the .ecl change
appears.
> Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com> # docs
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH v4] misra: allow discarding 'noreturn' during conversions
2025-08-01 10:53 ` Jan Beulich
@ 2025-08-01 10:58 ` Nicola Vetrini
2025-08-01 11:22 ` Dmytro Prokopchuk1
1 sibling, 0 replies; 4+ messages in thread
From: Nicola Vetrini @ 2025-08-01 10:58 UTC (permalink / raw)
To: Jan Beulich
Cc: Dmytro Prokopchuk1, Doug Goldstein, Stefano Stabellini,
Andrew Cooper, Anthony PERARD, Michal Orzel, Julien Grall,
Roger Pau Monné, xen-devel
On 2025-08-01 12:53, Jan Beulich wrote:
> On 01.08.2025 12:48, Dmytro Prokopchuk1 wrote:
>> The conversion from a function pointer with the 'noreturn' attribute
>> ('void noreturn (*)(...)') to a function pointer type ('void (*)(...)'
>> causes type incompatibility according to MISRA C Rule 11.1, which
>> forbids conversions between incompatible function pointer types.
>
> This wider deviation ...
>
>> 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 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.
>>
>> Configure ECLAIR to treat implicit conversions that lose the
>> "noreturn"
>> attribute on a function 'void (*)(void*)' as safe.
>
> ... wants connecting to this more narrow Eclair configuration. That's
> what
> I meant when I said "description also suitably adjusted". For example,
> the
> last sentence above could start "For now, configure Eclair to just
> treat
> ...". Can adjust when committing, assuming an ack for the .ecl change
> appears.
>
>> Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
>
> Acked-by: Jan Beulich <jbeulich@suse.com> # docs
Feels weird to review my own ecl honestly, but for the sake of the patch
I verified that it is indeed what I wrote, so
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com> # ECLAIR
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH v4] misra: allow discarding 'noreturn' during conversions
2025-08-01 10:53 ` Jan Beulich
2025-08-01 10:58 ` Nicola Vetrini
@ 2025-08-01 11:22 ` Dmytro Prokopchuk1
1 sibling, 0 replies; 4+ messages in thread
From: Dmytro Prokopchuk1 @ 2025-08-01 11:22 UTC (permalink / raw)
To: Jan Beulich
Cc: Nicola Vetrini, Doug Goldstein, Stefano Stabellini, Andrew Cooper,
Anthony PERARD, Michal Orzel, Julien Grall, Roger Pau Monné,
xen-devel@lists.xenproject.org
On 8/1/25 13:53, Jan Beulich wrote:
> On 01.08.2025 12:48, Dmytro Prokopchuk1 wrote:
>> The conversion from a function pointer with the 'noreturn' attribute
>> ('void noreturn (*)(...)') to a function pointer type ('void (*)(...)'
>> causes type incompatibility according to MISRA C Rule 11.1, which
>> forbids conversions between incompatible function pointer types.
>
> This wider deviation ...
>
>> 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 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.
>>
>> Configure ECLAIR to treat implicit conversions that lose the "noreturn"
>> attribute on a function 'void (*)(void*)' as safe.
>
> ... wants connecting to this more narrow Eclair configuration. That's what
> I meant when I said "description also suitably adjusted". For example, the
> last sentence above could start "For now, configure Eclair to just treat
> ...". Can adjust when committing, assuming an ack for the .ecl change
> appears.
>
>> Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
>
> Acked-by: Jan Beulich <jbeulich@suse.com> # docs
Sorry, I misunderstood.
Feel free to update the commit message.
Thank you!
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-08-01 11:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-01 10:48 [PATCH v4] misra: allow discarding 'noreturn' during conversions Dmytro Prokopchuk1
2025-08-01 10:53 ` Jan Beulich
2025-08-01 10:58 ` Nicola Vetrini
2025-08-01 11:22 ` Dmytro Prokopchuk1
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.