From: Jan Beulich <jbeulich@suse.com>
To: Nicola Vetrini <nicola.vetrini@bugseng.com>
Cc: sstabellini@kernel.org, consulting@bugseng.com,
Andrew Cooper <andrew.cooper3@citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 2/2] xen/cpu: address MISRA C Rule 17.7
Date: Mon, 26 Feb 2024 09:06:01 +0100 [thread overview]
Message-ID: <33342a17-e71c-4752-a16f-da5c0ef77b51@suse.com> (raw)
In-Reply-To: <dd4ac0e670a2ad7ecb5eb435e5e3b4b313b1e0b6.1708680104.git.nicola.vetrini@bugseng.com>
On 23.02.2024 10:35, Nicola Vetrini wrote:
> Refactor cpu_notifier_call_chain into two functions:
> - the variant that is allowed to fail loses the nofail flag
> - the variant that shouldn't fail is encapsulated in a call
> to the failing variant, with an additional check.
>
> This prevents uses of the function that are not supposed to
> fail from ignoring the return value, thus violating Rule 17.7:
> "The value returned by a function having non-void return type shall
> be used".
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
I'm afraid I disagree with this kind of bifurcation. No matter what
Misra thinks or says, it is normal for return values of functions to
not always be relevant to check. To deal with the Misra rule imo
requires to first have an abstract plan of how to handle such
globally in the code base. Imo such a plan can't be to introduce
perhaps dozens of new wrapper functions like is done here.
Jan
next prev parent reply other threads:[~2024-02-26 8:06 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-23 9:35 [XEN PATCH 0/2] address some violations of MISRA C Rule 17.7 Nicola Vetrini
2024-02-23 9:35 ` [XEN PATCH 1/2] xen/console: drop return value from consoled_guest_rx/tx Nicola Vetrini
2024-02-23 22:56 ` Stefano Stabellini
2024-02-26 8:00 ` Jan Beulich
2024-02-26 8:23 ` Nicola Vetrini
2024-02-26 8:56 ` Jan Beulich
2024-02-26 22:49 ` Stefano Stabellini
2024-02-27 7:08 ` Jan Beulich
2024-02-28 2:01 ` Stefano Stabellini
2024-02-23 9:35 ` [XEN PATCH 2/2] xen/cpu: address MISRA C Rule 17.7 Nicola Vetrini
2024-02-23 22:58 ` Stefano Stabellini
2024-02-26 8:06 ` Jan Beulich [this message]
2024-02-27 0:26 ` Stefano Stabellini
2024-02-27 7:28 ` Jan Beulich
2024-02-27 11:52 ` Julien Grall
2024-02-27 12:47 ` Jan Beulich
2024-02-28 2:10 ` Stefano Stabellini
2024-02-28 11:09 ` Nicola Vetrini
2024-02-28 11:36 ` Julien Grall
2024-02-28 22:38 ` Stefano Stabellini
2024-02-29 9:56 ` Nicola Vetrini
2024-02-28 11:06 ` Nicola Vetrini
2024-02-28 11:22 ` 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=33342a17-e71c-4752-a16f-da5c0ef77b51@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=consulting@bugseng.com \
--cc=george.dunlap@citrix.com \
--cc=julien@xen.org \
--cc=nicola.vetrini@bugseng.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.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.