Xen-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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


  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