automation/eclair_analysis/ECLAIR/deviations.ecl | 7 +++++++ docs/misra/deviations.rst | 6 ++++++ docs/misra/rules.rst | 3 ++- 3 files changed, 15 insertions(+), 1 deletion(-)
ECLAIR reports a non-compliant cast due to the presence
of the 'noreturn' attribute in the callee function.
The issue occurs when casting a function pointer with
the 'noreturn' attribute (void noreturn (*)(void *))
to a general function pointer type (void (*)(void *)).
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/
Test CI pipeline:
https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/1953370442
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 7 +++++++
docs/misra/deviations.rst | 6 ++++++
docs/misra/rules.rst | 3 ++-
3 files changed, 15 insertions(+), 1 deletion(-)
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..4e430bb17e 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -342,6 +342,12 @@ 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 (*)(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.
+ - 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..82a26162a9 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -404,7 +404,8 @@ maintainers if you want to suggest a change.
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.
+ bool and void* are permitted. Conversions from 'void noreturn (*)(void *)'
+ to 'void (*)(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
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. Jan
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.
>
> Jan
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.
Configure ECLAIR to treat 'noreturn' attributes as safe.
Dmytro.
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.
This one is still way to imprecise, though. And I hope it's only this
description, not also the Eclair configuration item that's overly lax.
Jan
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*)
> This one is still way to imprecise, though. And I hope it's only this
> description, not also the Eclair configuration item that's overly lax.
>
> Jan
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
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
© 2016 - 2025 Red Hat, Inc.