Rule 11.1 states as following: "Conversions shall not be performed
between a pointer to a function and any other type."

This deviation from Rule 11.1 relies on both ABI definitions and compiler
implementations supported by Xen. The System V x86_64 ABI and the AArch64
ELF ABI define consistent and compatible representations (i.e., having
the same size and memory layout) for (void *), unsigned long, and function
pointers, enabling safe conversions between these types without data loss
or corruption. Additionally, GCC and Clang, faithfully implement the ABI
specifications, ensuring that the generated machine code conforms to these
guarantees. Developers must note that this behavior is not universal and
depends on platform-specific ABIs and compiler implementations.

Configure Eclair to avoid reporting violations for conversions from
unsigned long or (void *) to a function pointer.

Add a compile-time assertion into the file 'xen/common/version.c' to
confirm this conversion compatibility across all target platforms
(assuming this file is common for all platforms).

References:
- System V x86_64 ABI: https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build
- AArch64 ELF ABI: https://github.com/ARM-software/abi-aa/releases
- GCC: https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
- Clang: https://clang.llvm.org/docs/CrossCompilation.html

Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
Changes in v2:
- updated commit message and deviation wording
- added Nicola's tag
- replaced "(void \*)" by a quoted form in one place

Link to v1:
https://patchew.org/Xen/9e5e4ff2c7ba0a90a6ac403e2de9318e18949274.1755628705.git.dmytro._5Fprokopchuk1@epam.com/
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 10 ++++++++++
 docs/misra/deviations.rst                        | 13 ++++++++++++-
 docs/misra/rules.rst                             |  7 ++++++-
 xen/common/version.c                             | 11 +++++++++++
 4 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 7f3fd35a33..432a68ae5a 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -375,6 +375,16 @@ constant expressions are required.\""
 }
 -doc_end
 
+-doc_begin="The conversion from unsigned long or (void *) to a function pointer is safe because it relies on both ABI definitions and compiler implementations supported by Xen
+which define consistent and compatible representations (i.e., having the same size and memory layout) for (void *), unsigned long, and function pointers, enabling safe
+conversions between these types without data loss or corruption."
+-config=MC3A2.R11.1,casts+={safe,
+  "from(type(canonical(builtin(unsigned long)||pointer(builtin(void)))))
+   &&to(type(canonical(__function_pointer_types)))
+   &&relation(definitely_preserves_value)"
+}
+-doc_end
+
 -doc_begin="The conversion from a function pointer to a boolean has a well-known semantics that do not lead to unexpected behaviour."
 -config=MC3A2.R11.1,casts+={safe,
   "from(type(canonical(__function_pointer_types)))
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 3271317206..565e65a6a3 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -366,11 +366,22 @@ Deviations related to MISRA C:2012 Rules:
      - Tagged as `safe` for ECLAIR.
 
    * - R11.1
-     - The conversion from a function pointer to unsigned long or (void \*) does
+     - The conversion from a function pointer to unsigned long or '(void *)' does
        not lose any information, provided that the target type has enough bits
        to store it.
      - Tagged as `safe` for ECLAIR.
 
+   * - R11.1
+     - The conversion from unsigned long or '(void *)' to a function pointer is
+       safe because it relies on both ABI definitions and compiler implementations
+       supported by Xen which define consistent and compatible representations
+       (i.e., having the same size and memory layout) for '(void *)', unsigned
+       long, and function pointers, enabling safe conversions between these types
+       without data loss or corruption. The compile-time assertions (BUILD_BUG_ON
+       macro) is integrated into 'xen/common/version.c' to confirm conversions
+       compatibility across all target platforms.
+     - Tagged as `safe` for ECLAIR.
+
    * - R11.1
      - The conversion from a function pointer to a boolean has a well-known
        semantics that do not lead to unexpected behaviour.
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 4388010ec9..4e94251887 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -431,7 +431,12 @@ maintainers if you want to suggest a change.
      - 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. Conversions from 'void noreturn (*)(...)'
-       to 'void (*)(...)' are permitted.
+       to 'void (*)(...)' are permitted. Conversions from unsigned long or
+       '(void *)' to a function pointer are permitted.
+       Example::
+
+           unsigned long func_addr = (unsigned long)&some_function;
+           void (*restored_func)(void) = (void (*)(void))func_addr;
 
    * - `Rule 11.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_02.c>`_
      - Required
diff --git a/xen/common/version.c b/xen/common/version.c
index 553b97ba9b..7091a6d440 100644
--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -217,6 +217,17 @@ void __init xen_build_init(void)
 #endif /* CONFIG_X86 */
 }
 #endif /* BUILD_ID */
+
+static void __init __maybe_unused build_assertions(void)
+{
+    /*
+     * To confirm conversion compatibility between unsigned long, (void *)
+     * and function pointers for all supported architectures.
+     */
+    BUILD_BUG_ON(sizeof(unsigned long) != sizeof(void (*)(void)));
+    BUILD_BUG_ON(sizeof(void *) != sizeof(void (*)(void)));
+}
+
 /*
  * Local variables:
  * mode: C
-- 
2.43.0

On 25.09.2025 10:04, Dmytro Prokopchuk1 wrote:
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -366,11 +366,22 @@ Deviations related to MISRA C:2012 Rules:
>       - Tagged as `safe` for ECLAIR.
>  
>     * - R11.1
> -     - The conversion from a function pointer to unsigned long or (void \*) does
> +     - The conversion from a function pointer to unsigned long or '(void *)' does
>         not lose any information, provided that the target type has enough bits
>         to store it.
>       - Tagged as `safe` for ECLAIR.
>  
> +   * - R11.1
> +     - The conversion from unsigned long or '(void *)' to a function pointer is
> +       safe because it relies on both ABI definitions and compiler implementations
> +       supported by Xen which define consistent and compatible representations
> +       (i.e., having the same size and memory layout) for '(void *)', unsigned
> +       long, and function pointers, enabling safe conversions between these types
> +       without data loss or corruption. The compile-time assertions (BUILD_BUG_ON
> +       macro) is integrated into 'xen/common/version.c' to confirm conversions
> +       compatibility across all target platforms.

As you use (and mean) plural, s/is/are/ ? I also think the "The" at the start
of the sentence wants dropping.

Further, why this very dissimilar wording compared to what's said about
conversions _from_ function pointer types?

And then ...

> --- a/xen/common/version.c
> +++ b/xen/common/version.c
> @@ -217,6 +217,17 @@ void __init xen_build_init(void)
>  #endif /* CONFIG_X86 */
>  }
>  #endif /* BUILD_ID */
> +
> +static void __init __maybe_unused build_assertions(void)
> +{
> +    /*
> +     * To confirm conversion compatibility between unsigned long, (void *)
> +     * and function pointers for all supported architectures.
> +     */
> +    BUILD_BUG_ON(sizeof(unsigned long) != sizeof(void (*)(void)));
> +    BUILD_BUG_ON(sizeof(void *) != sizeof(void (*)(void)));
> +}

... I'm unconvinced checking merely the sizes is sufficient. On architectures
involving function descriptors (e.g. ia64) converting in this direction is
safe only if earlier on the value was obtained as the result of a conversion
in the opposite direction (and all of this within a single component, which
of course is guaranteed for Xen).

Jan

On 9/25/25 16:25, Jan Beulich wrote:
> On 25.09.2025 10:04, Dmytro Prokopchuk1 wrote:
>> --- a/docs/misra/deviations.rst
>> +++ b/docs/misra/deviations.rst
>> @@ -366,11 +366,22 @@ Deviations related to MISRA C:2012 Rules:
>>        - Tagged as `safe` for ECLAIR.
>>   
>>      * - R11.1
>> -     - The conversion from a function pointer to unsigned long or (void \*) does
>> +     - The conversion from a function pointer to unsigned long or '(void *)' does
>>          not lose any information, provided that the target type has enough bits
>>          to store it.
>>        - Tagged as `safe` for ECLAIR.
>>   
>> +   * - R11.1
>> +     - The conversion from unsigned long or '(void *)' to a function pointer is
>> +       safe because it relies on both ABI definitions and compiler implementations
>> +       supported by Xen which define consistent and compatible representations
>> +       (i.e., having the same size and memory layout) for '(void *)', unsigned
>> +       long, and function pointers, enabling safe conversions between these types
>> +       without data loss or corruption. The compile-time assertions (BUILD_BUG_ON
>> +       macro) is integrated into 'xen/common/version.c' to confirm conversions
>> +       compatibility across all target platforms.
> 
> As you use (and mean) plural, s/is/are/ ? I also think the "The" at the start
> of the sentence wants dropping.
Ok.

> 
> Further, why this very dissimilar wording compared to what's said about
> conversions _from_ function pointer types?
Do you mean the following wording should be placed instead (to be 
similar with previous one)?

"Conversions from unsigned long or (void *) to a function pointer do not 
lose any information, provided that the source type has enough bits to 
restore it."

And wording about "ABI, compiler..." should be only in commit message?

> 
> And then ...
> 
>> --- a/xen/common/version.c
>> +++ b/xen/common/version.c
>> @@ -217,6 +217,17 @@ void __init xen_build_init(void)
>>   #endif /* CONFIG_X86 */
>>   }
>>   #endif /* BUILD_ID */
>> +
>> +static void __init __maybe_unused build_assertions(void)
>> +{
>> +    /*
>> +     * To confirm conversion compatibility between unsigned long, (void *)
>> +     * and function pointers for all supported architectures.
>> +     */
>> +    BUILD_BUG_ON(sizeof(unsigned long) != sizeof(void (*)(void)));
>> +    BUILD_BUG_ON(sizeof(void *) != sizeof(void (*)(void)));
>> +}
> 
> ... I'm unconvinced checking merely the sizes is sufficient. On architectures
> involving function descriptors (e.g. ia64) converting in this direction is
> safe only if earlier on the value was obtained as the result of a conversion
> in the opposite direction (and all of this within a single component, which
> of course is guaranteed for Xen).
As I know mainline Xen doesn't support IA-64 currently (this support was 
dropped).
Why we still need to mention about IA-64 here?

Anyway...
Yes, this deviation wouldn't work with architectures where the 
representation of a function involves more than just its address (e.g. 
IA-64). If not proved that such conversion is symmetric.

Probably, additional guard may be added below to exclude such 
architectures (e.g. IA-64):

static void __init __maybe_unused build_assertions(void)
{
#if defined (__IA64__) || defined (__ia64__)
#error "Conversions to function pointer isn't safe -  architecture uses 
function descriptors."
#endif

     BUILD_BUG_ON(sizeof(unsigned long) != sizeof(void (*)(void)));
     BUILD_BUG_ON(sizeof(void *) != sizeof(void (*)(void)));
}

But if someone really will try to run Xen on such platform, the build 
will fail.

Or just mention explicitly that other architectures (e.g., IA-64) might 
not be safe for such conversions?

Dmytro.>
> Jan

On 25.09.2025 20:37, Dmytro Prokopchuk1 wrote:
> On 9/25/25 16:25, Jan Beulich wrote:
>> On 25.09.2025 10:04, Dmytro Prokopchuk1 wrote:
>>> --- a/docs/misra/deviations.rst
>>> +++ b/docs/misra/deviations.rst
>>> @@ -366,11 +366,22 @@ Deviations related to MISRA C:2012 Rules:
>>>        - Tagged as `safe` for ECLAIR.
>>>   
>>>      * - R11.1
>>> -     - The conversion from a function pointer to unsigned long or (void \*) does
>>> +     - The conversion from a function pointer to unsigned long or '(void *)' does
>>>          not lose any information, provided that the target type has enough bits
>>>          to store it.
>>>        - Tagged as `safe` for ECLAIR.
>>>   
>>> +   * - R11.1
>>> +     - The conversion from unsigned long or '(void *)' to a function pointer is
>>> +       safe because it relies on both ABI definitions and compiler implementations
>>> +       supported by Xen which define consistent and compatible representations
>>> +       (i.e., having the same size and memory layout) for '(void *)', unsigned
>>> +       long, and function pointers, enabling safe conversions between these types
>>> +       without data loss or corruption. The compile-time assertions (BUILD_BUG_ON
>>> +       macro) is integrated into 'xen/common/version.c' to confirm conversions
>>> +       compatibility across all target platforms.
>>
>> As you use (and mean) plural, s/is/are/ ? I also think the "The" at the start
>> of the sentence wants dropping.
> Ok.
> 
>>
>> Further, why this very dissimilar wording compared to what's said about
>> conversions _from_ function pointer types?
> Do you mean the following wording should be placed instead (to be 
> similar with previous one)?
> 
> "Conversions from unsigned long or (void *) to a function pointer do not 
> lose any information, provided that the source type has enough bits to 
> restore it."
> 
> And wording about "ABI, compiler..." should be only in commit message?

Perhaps.

>> And then ...
>>
>>> --- a/xen/common/version.c
>>> +++ b/xen/common/version.c
>>> @@ -217,6 +217,17 @@ void __init xen_build_init(void)
>>>   #endif /* CONFIG_X86 */
>>>   }
>>>   #endif /* BUILD_ID */
>>> +
>>> +static void __init __maybe_unused build_assertions(void)
>>> +{
>>> +    /*
>>> +     * To confirm conversion compatibility between unsigned long, (void *)
>>> +     * and function pointers for all supported architectures.
>>> +     */
>>> +    BUILD_BUG_ON(sizeof(unsigned long) != sizeof(void (*)(void)));
>>> +    BUILD_BUG_ON(sizeof(void *) != sizeof(void (*)(void)));
>>> +}
>>
>> ... I'm unconvinced checking merely the sizes is sufficient. On architectures
>> involving function descriptors (e.g. ia64) converting in this direction is
>> safe only if earlier on the value was obtained as the result of a conversion
>> in the opposite direction (and all of this within a single component, which
>> of course is guaranteed for Xen).
> As I know mainline Xen doesn't support IA-64 currently (this support was 
> dropped).
> Why we still need to mention about IA-64 here?

Because I needed to use an example I know. Aiui there are other architectures
which use function descriptors (or alike).

> Anyway...
> Yes, this deviation wouldn't work with architectures where the 
> representation of a function involves more than just its address (e.g. 
> IA-64). If not proved that such conversion is symmetric.
> 
> Probably, additional guard may be added below to exclude such 
> architectures (e.g. IA-64):
> 
> static void __init __maybe_unused build_assertions(void)
> {
> #if defined (__IA64__) || defined (__ia64__)
> #error "Conversions to function pointer isn't safe -  architecture uses 
> function descriptors."
> #endif

Well, no, I didn't mean to ask that you add dead code.

>      BUILD_BUG_ON(sizeof(unsigned long) != sizeof(void (*)(void)));
>      BUILD_BUG_ON(sizeof(void *) != sizeof(void (*)(void)));
> }
> 
> But if someone really will try to run Xen on such platform, the build 
> will fail.
> 
> Or just mention explicitly that other architectures (e.g., IA-64) might 
> not be safe for such conversions?

My main point really is that once again I wonder how convincing such an
argument would be to assessors, when it's clearly not generic (yet being
worded and the checking coded as if it was).

Jan

On 2025-09-26 08:46, Jan Beulich wrote:
> On 25.09.2025 20:37, Dmytro Prokopchuk1 wrote:
>> On 9/25/25 16:25, Jan Beulich wrote:
>>> On 25.09.2025 10:04, Dmytro Prokopchuk1 wrote:
>>>> --- a/docs/misra/deviations.rst
>>>> +++ b/docs/misra/deviations.rst
>>>> @@ -366,11 +366,22 @@ Deviations related to MISRA C:2012 Rules:
>>>>        - Tagged as `safe` for ECLAIR.
>>>> 
>>>>      * - R11.1
>>>> -     - The conversion from a function pointer to unsigned long or 
>>>> (void \*) does
>>>> +     - The conversion from a function pointer to unsigned long or 
>>>> '(void *)' does
>>>>          not lose any information, provided that the target type has 
>>>> enough bits
>>>>          to store it.
>>>>        - Tagged as `safe` for ECLAIR.
>>>> 
>>>> +   * - R11.1
>>>> +     - The conversion from unsigned long or '(void *)' to a 
>>>> function pointer is
>>>> +       safe because it relies on both ABI definitions and compiler 
>>>> implementations
>>>> +       supported by Xen which define consistent and compatible 
>>>> representations
>>>> +       (i.e., having the same size and memory layout) for '(void 
>>>> *)', unsigned
>>>> +       long, and function pointers, enabling safe conversions 
>>>> between these types
>>>> +       without data loss or corruption. The compile-time assertions 
>>>> (BUILD_BUG_ON
>>>> +       macro) is integrated into 'xen/common/version.c' to confirm 
>>>> conversions
>>>> +       compatibility across all target platforms.
>>> 
>>> As you use (and mean) plural, s/is/are/ ? I also think the "The" at 
>>> the start
>>> of the sentence wants dropping.
>> Ok.
>> 
>>> 
>>> Further, why this very dissimilar wording compared to what's said 
>>> about
>>> conversions _from_ function pointer types?
>> Do you mean the following wording should be placed instead (to be
>> similar with previous one)?
>> 
>> "Conversions from unsigned long or (void *) to a function pointer do 
>> not
>> lose any information, provided that the source type has enough bits to
>> restore it."
>> 
>> And wording about "ABI, compiler..." should be only in commit message?
> 
> Perhaps.
> 
>>> And then ...
>>> 
>>>> --- a/xen/common/version.c
>>>> +++ b/xen/common/version.c
>>>> @@ -217,6 +217,17 @@ void __init xen_build_init(void)
>>>>   #endif /* CONFIG_X86 */
>>>>   }
>>>>   #endif /* BUILD_ID */
>>>> +
>>>> +static void __init __maybe_unused build_assertions(void)
>>>> +{
>>>> +    /*
>>>> +     * To confirm conversion compatibility between unsigned long, 
>>>> (void *)
>>>> +     * and function pointers for all supported architectures.
>>>> +     */
>>>> +    BUILD_BUG_ON(sizeof(unsigned long) != sizeof(void (*)(void)));
>>>> +    BUILD_BUG_ON(sizeof(void *) != sizeof(void (*)(void)));
>>>> +}
>>> 
>>> ... I'm unconvinced checking merely the sizes is sufficient. On 
>>> architectures
>>> involving function descriptors (e.g. ia64) converting in this 
>>> direction is
>>> safe only if earlier on the value was obtained as the result of a 
>>> conversion
>>> in the opposite direction (and all of this within a single component, 
>>> which
>>> of course is guaranteed for Xen).
>> As I know mainline Xen doesn't support IA-64 currently (this support 
>> was
>> dropped).
>> Why we still need to mention about IA-64 here?
> 
> Because I needed to use an example I know. Aiui there are other 
> architectures
> which use function descriptors (or alike).
> 
>> Anyway...
>> Yes, this deviation wouldn't work with architectures where the
>> representation of a function involves more than just its address (e.g.
>> IA-64). If not proved that such conversion is symmetric.
>> 
>> Probably, additional guard may be added below to exclude such
>> architectures (e.g. IA-64):
>> 
>> static void __init __maybe_unused build_assertions(void)
>> {
>> #if defined (__IA64__) || defined (__ia64__)
>> #error "Conversions to function pointer isn't safe -  architecture 
>> uses
>> function descriptors."
>> #endif
> 
> Well, no, I didn't mean to ask that you add dead code.
> 
>>      BUILD_BUG_ON(sizeof(unsigned long) != sizeof(void (*)(void)));
>>      BUILD_BUG_ON(sizeof(void *) != sizeof(void (*)(void)));
>> }
>> 
>> But if someone really will try to run Xen on such platform, the build
>> will fail.
>> 
>> Or just mention explicitly that other architectures (e.g., IA-64) 
>> might
>> not be safe for such conversions?
> 
> My main point really is that once again I wonder how convincing such an
> argument would be to assessors, when it's clearly not generic (yet 
> being
> worded and the checking coded as if it was).
> 
> Jan

Well, it is true that the intended scope of those deviations is for the 
architectures and compilers that are subject to the analysis, because 
adding a new architecture or compiler to the mix would mean that all the 
assumptions need to be re-evaluated for that compiler/arch (this is an 
IDB in the first place, so it is unlikely that a general statement can 
be made). Perhaps the BUILD_BUG_ON should be limited to these 
arch-es/compilers, so that there is little doubt about the intended 
motivation of the check.

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253