Re: [PATCH 01/39] docs/spin: replace assert(0) with g_assert_not_reached()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/11/24 05:51, Richard W.M. Jones wrote:
On Wed, Sep 11, 2024 at 02:46:18PM +0200, Maciej S. Szmigiero wrote:
On 11.09.2024 14:37, Eric Blake wrote:
On Wed, Sep 11, 2024 at 07:33:59AM GMT, Eric Blake wrote:
On Tue, Sep 10, 2024 at 03:15:28PM GMT, Pierrick Bouvier wrote:
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@xxxxxxxxxx>
---

A general suggestion for the entire series: please use a commit
message that explains why this is a good idea.  Even something as
boiler-plate as "refer to commit XXX for rationale" that can be
copy-pasted into all the other commits is better than nothing,
although a self-contained message is best.  Maybe:

This patch is part of a series that moves towards a consistent use of
g_assert_not_reached() rather than an ad hoc mix of different
assertion mechanisms.

Or summarize your cover letter:

Use of assert(false) can trip spurious control flow warnings from some
versions of gcc:
https://lore.kernel.org/qemu-devel/54bb02a6-1b12-460a-97f6-3f478ef766c6@xxxxxxxxxx/
Solve that by unifying the code base on g_assert_not_reached()
instead.


If using g_assert_not_reached() instead of assert(false) silences
the warning about missing return value in such impossible to reach
locations should we also be deleting the now-unnecessary "return"
statements after g_assert_not_reached()?

Although it's unlikely to be used on any compiler that can also
compile qemu, there is a third implementation of g_assert_not_reached
that does nothing, see:

https://gitlab.gnome.org/GNOME/glib/-/blob/927683ebd94eb66c0d7868b77863f57ce9c5bc76/glib/gtestutils.h#L269

Rich.


Interesting.
At least gcc, clang and msvc are covered, this should be ok for most of the builds.

Thanks for sharing,
Pierrick




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux