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 3/4] Eclair: relax "noreturn" function-pointer conversion deviation
Date: Sat, 12 Sep 2026 18:04:43 +0200	[thread overview]
Message-ID: <3d473b8a85331856ea2b95f9448f2d6c@bugseng.com> (raw)
In-Reply-To: <4cca58b6-b555-4064-aa26-5204dc4b99cc@suse.com>

On 2026-09-03 13:44, Jan Beulich wrote:
> Like misra/rules.rst says, function arguments other than "void *" are 
> okay
> as well.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> I can't explain why this covers the violation in mce.c:mce_callbacks'es
> initializer, but not the one in mce.c:default_handler's.
> 

Possibly differing attributes (e.g. cf_check vs section attributes)? 
Just a guess that would need to be tested, though.

> As a result of 6852334f8416 ("Arm/GIC: add noreturn in a few more
> places"), vgic_v2_lpi_to_pending() and vgic_v2_lpi_get_priority() (both
> returning non-void) would also need covering. (As said in a remark 
> there,
> non-void together with noreturn is somewhat odd.)
> 

Indeed

> Really before and after this change there's no checking that parameter 
> and
> return types actually match. I have no clue how one would express such
> checks.

The presence of a bitcast indicates that the two types do not match 
exactly. Typically function attributes are not relevant towards 
determining a type difference, but different compilers may model 
non-standard features differently (rightly so), in such a way that some 
make a difference in the AST, and others do not.

To check for compatibility of function pointers I would try activating 
service STD.funptrcv, which essentially mirrors 
-Wincompatible-pointer-types:

caution for rule STD.funptrcv: (rule) A pointer is used to call a 
function whose type is not compatible with the pointed-to type. 
(untagged)
p.c:8.8-8.8: Loc #1 [culprit: implicit cast converts from `void(*)(int)' 
to `__typeof__(@EXPR@)*' (that is `void(*)(void)')]
   qq = m;
        ^
p.c: In function ‘h’:
p.c:8:6: error: assignment to ‘void (*)(void)’ from incompatible pointer 
type ‘void (*)(int)’ [-Wincompatible-pointer-types]
     8 |   qq = m;
       |      ^
p.c:3:6: note: ‘m’ declared here
     3 | void m(int x);
       |      ^


> 
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -391,11 +391,11 @@ constant expressions are required.\""
>  }
>  -doc_end
> 
> --doc_begin="The conversion from 'void noreturn (*)(void *)' to 'void 
> (*)(void *)' is safe
> +-doc_begin="The conversion from 'void noreturn (*)(...)' to 'void 
> (*)(...)' is safe
>  because the semantics of the 'noreturn' attribute do not alter the 
> calling convention or behavior of the resulting code."
>  -config=MC3A2.R11.1,casts+={safe,
> -  
> "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))&&all_param(1, 
> pointer(builtin(void)))))))&&from(expr(skip(!syntactic(),
> -   ref(property(noreturn)))))"}
> +  
> "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))))))&&from(expr(skip(!syntactic(),ref(property(noreturn)))))"
> +}
>  -doc_end
> 
>  -doc_begin="The conversion from a pointer to an incomplete type to 
> unsigned long does not lose any information, provided that the target 
> type has enough bits to store it."

-- 
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 16:05 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
2026-09-03 11:44 ` [PATCH 3/4] Eclair: relax "noreturn" " Jan Beulich
2026-09-12 16:04   ` Nicola Vetrini [this message]
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=3d473b8a85331856ea2b95f9448f2d6c@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.