[PATCH] misra/eclair: set 'noreturn' attribute as safe during cast

[PATCH] misra/eclair: set 'noreturn' attribute as safe during cast

[Dmytro Prokopchuk1]

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

Re: [PATCH] misra/eclair: set 'noreturn' attribute as safe during cast

[Jan Beulich]

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

Re: [PATCH] misra/eclair: set 'noreturn' attribute as safe during cast

[Dmytro Prokopchuk1]

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.

Re: [PATCH] misra/eclair: set 'noreturn' attribute as safe during cast

[Jan Beulich]

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

Re: [PATCH] misra/eclair: set 'noreturn' attribute as safe during cast

[Nicola Vetrini]

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

Re: [PATCH] misra/eclair: set 'noreturn' attribute as safe during cast

[Jan Beulich]

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