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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 21.08.2025 10: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.
> 
>>> --- 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)

But everything here is bullet-pointed (with at least two levels)?

Jan