All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Dmytro Prokopchuk1 <dmytro_prokopchuk1@epam.com>
Cc: "Nicola Vetrini" <nicola.vetrini@bugseng.com>,
	"Doug Goldstein" <cardoe@cardoe.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Anthony PERARD" <anthony.perard@vates.tech>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Julien Grall" <julien@xen.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2] misra: consider conversion from UL or (void*) to function pointer as safe
Date: Thu, 25 Sep 2025 15:25:57 +0200	[thread overview]
Message-ID: <ae0ecbfc-cee0-4035-ba03-e9f9ba2661e4@suse.com> (raw)
In-Reply-To: <b0f269822312a442e87ab02c8deff028b6b040a9.1758787340.git.dmytro_prokopchuk1@epam.com>

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


  reply	other threads:[~2025-09-25 13:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-25  8:04 [PATCH v2] misra: consider conversion from UL or (void*) to function pointer as safe Dmytro Prokopchuk1
2025-09-25 13:25 ` Jan Beulich [this message]
2025-09-25 18:37   ` Dmytro Prokopchuk1
2025-09-26  6:46     ` Jan Beulich
2025-09-26  7:58       ` Nicola Vetrini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae0ecbfc-cee0-4035-ba03-e9f9ba2661e4@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=cardoe@cardoe.com \
    --cc=dmytro_prokopchuk1@epam.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=nicola.vetrini@bugseng.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.