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