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.vetr...@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. 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 >>>> >
