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

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

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