From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Julien Grall" <julien@xen.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Anthony PERARD" <anthony.perard@vates.tech>,
"Michal Orzel" <michal.orzel@amd.com>,
"Roger Pau Monné" <roger@xenproject.org>
Subject: Re: [PATCH 2/4] Eclair: relax long <-> function-pointer conversion deviation
Date: Sat, 12 Sep 2026 17:19:06 +0200 [thread overview]
Message-ID: <43e412de9e5165f33c572841bfc58dc9@bugseng.com> (raw)
In-Reply-To: <fca27ac3-95c9-4177-a9cd-673f07230889@suse.com>
On 2026-09-03 13:43, Jan Beulich wrote:
> What is true for unsigned long is also true for plain/signed long, thus
> also taking care of two instances of __x86_return_thunk() being cast to
> long.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Some nits below:
>
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -368,17 +368,17 @@ constant expressions are required.\""
> # Series 11
> #
>
> --doc_begin="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."
> +-doc_begin="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."
> -config=MC3A2.R11.1,casts+={safe,
> "from(type(canonical(__function_pointer_types)))
> - &&to(type(canonical(builtin(unsigned
> long)||pointer(builtin(void)))))
> + &&to(type(canonical(builtin(long)||builtin(unsigned
> long)||pointer(builtin(void)))))
> &&relation(definitely_preserves_value)"
> }
could be canonical(builtin(long||unsigned long))||pointer(builtin(void))
> -doc_end
>
> --doc_begin="Conversion from unsigned long or (void *) to a function
> pointer can restore full information, provided that the source type has
> enough bits to restore it."
> +-doc_begin="Conversion from [unsigned] long or (void *) to a function
> pointer can restore full information, provided that the source type has
> enough bits to restore it."
> -config=MC3A2.R11.1,casts+={safe,
> - "from(type(canonical(builtin(unsigned
> long)||pointer(builtin(void)))))
> + "from(type(canonical(builtin(long)||builtin(unsigned
> long)||pointer(builtin(void)))))
> &&to(type(canonical(__function_pointer_types)))
> &&relation(definitely_preserves_value)"
> }
Same as above
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -432,8 +432,8 @@ maintainers if you want to suggest a cha
> - 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. Conversions from unsigned
> long or
> - '(void *)' to a function pointer are permitted.
> + to 'void (*)(...)' are permitted. Conversions from [unsigned]
> long
> + or '(void *)' to a function pointer are permitted.
> Example::
>
> unsigned long func_addr = (unsigned long)&some_function;
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
next prev parent reply other threads:[~2026-09-12 15:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 11:42 [PATCH 0/4] address most remaining rule 11.1 violations Jan Beulich
2026-09-03 11:43 ` [PATCH 1/4] x86/domain: address Misra rule 11.1 violation in reset_stack_and_call_ind() Jan Beulich
2026-09-12 15:09 ` Nicola Vetrini
2026-09-03 11:43 ` [PATCH 2/4] Eclair: relax long <-> function-pointer conversion deviation Jan Beulich
2026-09-12 15:19 ` Nicola Vetrini [this message]
2026-09-03 11:44 ` [PATCH 3/4] Eclair: relax "noreturn" " Jan Beulich
2026-09-12 16:04 ` Nicola Vetrini
2026-09-03 11:44 ` [PATCH 4/4] x86/kexec: address Misra rule 11.1 violation in machine_kexec_load() Jan Beulich
2026-09-12 16:06 ` Nicola Vetrini
2026-09-03 11:45 ` [PATCH 0/4] address most remaining rule 11.1 violations Jan Beulich
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=43e412de9e5165f33c572841bfc58dc9@bugseng.com \
--to=nicola.vetrini@bugseng.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=roger@xenproject.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox