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

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 2025-08-28 17:54, Dmytro Prokopchuk1 wrote:
> 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.vetrini@xxxxxxxxxxx>
> 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.
LGTM.

> 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
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253