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
