[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2] misra: consider conversion from UL or (void*) to function pointer as safe
On 25.09.2025 10:04, Dmytro Prokopchuk1 wrote: > --- a/docs/misra/deviations.rst > +++ b/docs/misra/deviations.rst > @@ -366,11 +366,22 @@ Deviations related to MISRA C:2012 Rules: > - Tagged as `safe` for ECLAIR. > > * - R11.1 > - - The conversion from a function pointer to unsigned long or (void \*) > does > + - The conversion from a function pointer to unsigned long or '(void *)' > does > not lose any information, provided that the target type has enough > bits > to store it. > - Tagged as `safe` for ECLAIR. > > + * - R11.1 > + - The conversion from unsigned long or '(void *)' to a function pointer > is > + safe because it relies on both ABI definitions and compiler > implementations > + supported by Xen which 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. The compile-time assertions > (BUILD_BUG_ON > + macro) is integrated into 'xen/common/version.c' to confirm > conversions > + compatibility across all target platforms. As you use (and mean) plural, s/is/are/ ? I also think the "The" at the start of the sentence wants dropping. Further, why this very dissimilar wording compared to what's said about conversions _from_ function pointer types? And then ... > --- a/xen/common/version.c > +++ b/xen/common/version.c > @@ -217,6 +217,17 @@ void __init xen_build_init(void) > #endif /* CONFIG_X86 */ > } > #endif /* BUILD_ID */ > + > +static void __init __maybe_unused build_assertions(void) > +{ > + /* > + * To confirm conversion compatibility between unsigned long, (void *) > + * and function pointers for all supported architectures. > + */ > + BUILD_BUG_ON(sizeof(unsigned long) != sizeof(void (*)(void))); > + BUILD_BUG_ON(sizeof(void *) != sizeof(void (*)(void))); > +} ... I'm unconvinced checking merely the sizes is sufficient. On architectures involving function descriptors (e.g. ia64) converting in this direction is safe only if earlier on the value was obtained as the result of a conversion in the opposite direction (and all of this within a single component, which of course is guaranteed for Xen). Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |