All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Roberto Bagnara" <roberto.bagnara@bugseng.com>,
	Xen-devel <xen-devel@lists.xenproject.org>,
	"Jan Beulich" <JBeulich@suse.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Julien Grall" <julien@xen.org>,
	"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
	"Bertrand Marquis" <bertrand.marquis@arm.com>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"consulting @ bugseng . com" <consulting@bugseng.com>
Subject: Re: [PATCH 09/12] x86/shadow: Rework write_atomic() call in shadow_write_entries()
Date: Wed, 25 Feb 2026 13:35:01 +0100	[thread overview]
Message-ID: <678f1a67603d4b37d717dc84565db044@bugseng.com> (raw)
In-Reply-To: <278f711d-7c61-4a47-868e-ab05b9426e40@citrix.com>

On 2026-02-25 13:14, Andrew Cooper wrote:
> On 23/02/2026 7:26 am, Roberto Bagnara wrote:
>> On 20/02/26 22:46, Andrew Cooper wrote:
>>> Eclair complains of a side effect in a sizeof() expression (R13.6).
>> 
>> I disagree with comments of the form "Eclair complains"
> 
> We use the same phrasing with other tools too, but I can change it to
> "reports" which I suppose is a more neutral term.
> 
>> 
>> Note that in recent versions of MISRA C that rule is no longer
>> mandatory.  More generally, note also that, IMHO, switching to
>> a more modern version of MISRA C would simplify compliance.
> 
> Ok.  Making things simpler for compliance sounds like a good thing. 
> What would this entail?
> 
> Presumably we've got to adapt to all changes in this newer revision of
> MISRA C.
> 
> ~Andrew

Most likely new violations on new non-clean guidelines, generally rules 
for features that were standardized in C11/C18 and were previously 
widely available extensions (e.g. _Noreturn, _Alignof, threads, ...), 
alongside some minor changes in existing ones, such as the 
classification change mentioned by Roberto. The exact impact depends on 
the target MISRA revision, however. Making an experiment should be only 
a matter of s/MC3A2/MC4/ (or whichever MISRA revision is chosen: MC4 in 
ECLAIR refers to the latest published MISRA revision, that is, MISRA 
C:2025. Perhaps also a few regressions (as in newly introduced 
violations) on clean ones, but I do not expect the results to be 
radically different.

Side note here: are the efforts to make Xen compile with -stc=c11/gnu11 
still ongoing? I say this because any MISRA revision other than the one 
currently used by Xen by default is based on C11, as it introduces 
guidelines for C11/C18 features. Not that this would matter a whole lot 
for Xen, but it is something to consider in the broader picture.

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


  reply	other threads:[~2026-02-25 12:35 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-20 21:46 [PATCH 00/12] xen: Misc MISRA fixes for *-allcode targets Andrew Cooper
2026-02-20 21:46 ` [PATCH 01/12] arm: Use __func__ in acpi_boot_table_init() Andrew Cooper
2026-02-20 21:58   ` Nicola Vetrini
2026-02-23  8:54   ` Orzel, Michal
2026-02-20 21:46 ` [PATCH 02/12] xen/treewide: Adjust suffixes on integer literals Andrew Cooper
2026-02-23  8:57   ` Orzel, Michal
2026-02-20 21:46 ` [PATCH 03/12] xen/argo: Fix MISRA violations around function parameters Andrew Cooper
2026-02-23  9:15   ` Jan Beulich
2026-03-03 12:48     ` Daniel Smith
2026-02-20 21:46 ` [PATCH 04/12] xen/treewide: Adjust parameter names and types Andrew Cooper
2026-02-23  8:58   ` Orzel, Michal
2026-02-20 21:46 ` [PATCH 05/12] x86: Adjust annotations of asm-used identifiers Andrew Cooper
2026-02-23  9:21   ` Jan Beulich
2026-02-20 21:46 ` [PATCH 06/12] xen: Include suitable headers to make declarations visible Andrew Cooper
2026-02-23 10:44   ` Jan Beulich
2026-02-20 21:46 ` [PATCH 07/12] xen/vmac: Const the key parameter of vmac_set_key() Andrew Cooper
2026-02-23 10:45   ` Jan Beulich
2026-02-20 21:46 ` [PATCH 08/12] arm/pci-designware: Fix MISRA violations Andrew Cooper
2026-02-20 22:15   ` Nicola Vetrini
2026-02-23  9:00   ` Orzel, Michal
2026-02-20 21:46 ` [PATCH 09/12] x86/shadow: Rework write_atomic() call in shadow_write_entries() Andrew Cooper
2026-02-20 22:28   ` Nicola Vetrini
2026-02-23  7:26   ` Roberto Bagnara
2026-02-25 12:14     ` Andrew Cooper
2026-02-25 12:35       ` Nicola Vetrini [this message]
2026-02-25 12:53         ` Andrew Cooper
2026-02-25 13:09           ` Nicola Vetrini
2026-02-20 21:46 ` [PATCH 10/12] xen: Adjust break/fallthrough statements Andrew Cooper
2026-02-20 22:36   ` Nicola Vetrini
2026-02-23  9:02   ` Orzel, Michal
2026-02-20 21:46 ` [PATCH 11/12] xen: Bracket uses of macro parameters Andrew Cooper
2026-02-20 22:45   ` Nicola Vetrini
2026-02-25 16:05     ` Andrew Cooper
2026-02-25 16:34       ` Nicola Vetrini
2026-02-25 16:39         ` Andrew Cooper
2026-02-23  9:04   ` Orzel, Michal
2026-02-23 10:50   ` Jan Beulich
2026-02-20 21:46 ` [PATCH 12/12] xen/vmac: Delete STDINT block in vmac.h Andrew Cooper
2026-02-23 10:54   ` 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=678f1a67603d4b37d717dc84565db044@bugseng.com \
    --to=nicola.vetrini@bugseng.com \
    --cc=JBeulich@suse.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bertrand.marquis@arm.com \
    --cc=consulting@bugseng.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=roberto.bagnara@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.