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
