Re: [PATCH] misra: consider conversion from UL or (void*) to function pointer as safe

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.08.2025 20:55, Dmytro Prokopchuk1 wrote:
> Rule 11.1 states as following: "Conversions shall not be performed
> between a pointer to a function and any other type."
> 
> The conversion from unsigned long or (void *) to a function pointer
> is safe in Xen because the architectures it supports (e.g., x86 and
> ARM) guarantee compatible representations between these types.

I think we need to be as precise as possible here. The architectures
guarantee nothing, they only offer necessary fundamentals. In the
Windows x86 ABI, for example, you can't convert pointers to/from longs
without losing data. What we build upon is what respective ABIs say,
possibly in combination of implementation specifics left to compilers.

> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -370,6 +370,16 @@ Deviations related to MISRA C:2012 Rules:
>         to store it.
>       - Tagged as `safe` for ECLAIR.
>  
> +   * - R11.1
> +     - The conversion from unsigned long or (void \*) to a function pointer 
> does
> +       not lose any information or violate type safety assumptions if 
> unsigned
> +       long or (void \*) type is guaranteed to be the same bit size as a
> +       function pointer. This ensures that the function pointer can be fully
> +       represented without truncation or corruption. The macro BUILD_BUG_ON 
> is
> +       integrated into xen/common/version.c to confirm conversion 
> compatibility
> +       across all target platforms.
> +     - Tagged as `safe` for ECLAIR.

Why the escaping of * here, when ...

> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -431,7 +431,13 @@ 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 if the source type has
> +       enough bits to restore function pointer without truncation or 
> corruption.
> +       Example::
> +
> +           unsigned long func_addr = (unsigned long)&some_function;
> +           void (*restored_func)(void) = (void (*)(void))func_addr;

... context here suggests they work fine un-escaped, and you even add some un-
escaped instances as well. Perhaps I'm simply unaware of some peculiarity?

Jan