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

[Jan Beulich <jbeulich@suse.com>]

On 22.08.2025 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
> guarantee compatible representations for 'void *', 'unsigned long' and
> function pointers for the supported target platforms. This behavior is
> architecture-specific and may not be portable outside of supported
> environments.

Reads okay to me; for Arm64 I can only assume the psABI indeed makes this
guarantee.

>>>> --- 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: \*

Yet under "Example::" there's no quotation and no escaping. The one
"(void \*)" earlier in the text I'd suggest to replace by a quoted
form anyway, matching the rest of the text.

Jan