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