All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: QEMU tests, Coverity, and g_test_set_nonfatal_assertions()
Date: Wed, 05 May 2021 10:36:10 +0200	[thread overview]
Message-ID: <877dkdvapx.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <CAFEAcA9juOChqrh5orybJQwpQsyEZ5z3Dvmy7fjX0DW4Nbgmrg@mail.gmail.com> (Peter Maydell's message of "Mon, 3 May 2021 17:49:50 +0100")

Peter Maydell <peter.maydell@linaro.org> writes:

[...]

> In summary, we have a few options:
>
> (1) Expand "assertions always fatal" to test code, and add "panics"
> models of the g_assertion_message* functions. Remove all the calls
> to g_test_set_nonfatal_assertions().
>
> (2) Aim to expand the ability to use g_test_set_nonfatal_assertions()
> to other tests than the handful that currently use it (perhaps by
> providing a standard place where it gets called for all tests, though
> there isn't currently an obvious place to do that). Treat Coverity
> issues in our test code which flag up "this would crash if the
> assertion fired but execution continued" as bugs to be fixed (though
> not very high-priority ones, obviously).

Further discussed under Richard's reply.

> (3) Something else ?

We could try to model what the GLib functions do:
g_test_set_nonfatal_assertions() sets a global flag, the g_assert_FOO()
other than g_assert_not_reached() check it.  We'll then find out whether
Coverity's analysis is strong enough to propagate the value passed to
g_test_set_nonfatal_assertions() to its uses.

[...]



      parent reply	other threads:[~2021-05-05  8:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-03 16:49 QEMU tests, Coverity, and g_test_set_nonfatal_assertions() Peter Maydell
2021-05-03 17:15 ` Richard Henderson
2021-05-03 17:18   ` Peter Maydell
2021-05-05  8:36 ` Markus Armbruster [this message]

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=877dkdvapx.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.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.