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.vetr...@bugseng.com>
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
