All of 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 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.