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

[Nicola Vetrini <nicola.vetrini@bugseng.com>]

On 2025-08-28 17:54, Dmytro Prokopchuk1 wrote:
> On 8/25/25 16:08, Nicola Vetrini wrote:
>> On 2025-08-25 14:53, Nicola Vetrini wrote:
>>> On 2025-08-22 18:34, Dmytro Prokopchuk1 wrote:
>>>> On 8/21/25 11:25, Nicola Vetrini wrote:
>>>>> On 2025-08-21 10:01, Jan Beulich wrote:
>>>>>> 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.
>>>>>> 
>>>>> 
>>>>> +1, a mention of the compilers and targets this deviation relies
>>>>> upon is
>>>>> needed.
>>>> 
>>>> Maybe with this wording:
>>>> 
>>>> This deviation is based on the guarantees provided by the specific 
>>>> ABIs
>>>> (e.g., ARM AAPCS) and compilers (e.g., GCC) supported in Xen. These 
>>>> ABIs
>>> 
>>> s/supported in/supported by/
>>> 
>>>> guarantee compatible representations for 'void *', 'unsigned long' 
>>>> and
>>>> function pointers for the supported target platforms. This behavior 
>>>> is
>>> 
>>> It's not just about the guarantees of the ABIs: it's the behavior of
>>> the compiler for those ABIs that makes this safe or unsafe. If
>>> present, such documentation should be included
>>> 
>> 
>> In any case, provided that the wording can be adjusted:
>> 
>> Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> 
> Updated wording:
> 
> 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.
> 

LGTM.

> 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
> 
> Thanks,
> Dmytro.
>> 
>>>> architecture-specific and may not be portable outside of supported
>>>> environments.
>>>> 
>>>>> 
>>>>>>> --- 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?
>>>>>> 
>>>>> 
>>>>> This is a literal rst block, while the other is not (* acts as a 
>>>>> bullet
>>>>> point in rst iirc)
>>>> 
>>>> This is how "sphinx-build" tool interprets this.
>>>> 1. * inside single quotes '' -> looks normal, e.g. ‘void (*)(…)’
>>>> 2. * without quotes -> warning
>>>> deviations.rst:369: WARNING: Inline emphasis start-string without
>>>> end-string. [docutils]
>>>> 3. \* -> looks normal, e.g. (void *)
>>>> 
>>>> Because that we need such format: \*
>>>> 
>>>> Dmytro.
>>>> 
>>>>> 
>>>>>> Jan
>>>>> 
>> 

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