From: Peter Maydell <peter.maydell@linaro.org>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Laurent Vivier" <lvivier@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
qemu-devel <qemu-devel@nongnu.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: [PATCH] tests/unit/test-char.c: Fix error handling issues
Date: Wed, 9 Jun 2021 14:19:28 +0100 [thread overview]
Message-ID: <CAFEAcA8DMwg5mAVDq8GJggCu79eNw6ZLKnbs0wFDPv=-VhhpSQ@mail.gmail.com> (raw)
In-Reply-To: <87bl8fnrk8.fsf@dusky.pond.sub.org>
On Wed, 9 Jun 2021 at 13:36, Markus Armbruster <armbru@redhat.com> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Tue, 8 Jun 2021 at 20:51, Marc-André Lureau
> > <marcandre.lureau@redhat.com> wrote:
> >>
> >> Hi
> >>
> >> On Tue, Jun 8, 2021 at 9:06 PM Peter Maydell <peter.maydell@linaro.org> wrote:
> >>> I think that improving the quality of the failure reporting
> >>> in 'make check' is useful, and that we should probably turn
> >>> on g_test_set_nonfatal_assertions() everywhere. (The worst that
> >>> can happen is that instead of crashing on the assert we proceed
> >>> and crash a bit later, I think.) Awkwardly we don't have a single
> >>> place where we could put that call, so I guess it's a coccinelle
> >>> script to add it to every test's main() function.
> >>>
> >>
> >> I don't have any strong opinion on this. But I don't see much sense in
> >> having extra code for things that should never happen.
> >
> > The point is that I want to make them happen, though...
>
> I'd prefer not to.
>
> Writing tests is tedious enough as it is. Replacing
>
> assert COND in one of the many ways GLib provides
>
> by
>
> assert COND in one of the many ways GLib provides
> if (!COND) {
> bail out
> }
>
> makes it worse.
>
> Readability suffers, too.
I agree. But glib doesn't provide a "check this test thing I'm
trying to test, and make it cleanly abandon and fail the test
if the check passes" function. I suppose we could rig one up
with setjmp/longjmp and some macros...
> >> I would teach coverity instead that those asserts are always fatal.
> >
> > If you want an assert that's always fatal, that's g_assert().
> > These ones are documented as not always fatal.
>
> You'd sacrifice the additional output from g_assert_cmpint() & friends,
> which can sometimes save a trip through the debugger. I don't care all
> that much myself, but I know others do.
> Plain assert()'s behavior is configurable at compile time: assertion
> checking on / off. This sets a trap for the unwary: side effects in the
> argument. We avoid the trap by gluing the compile-time switch to "on".
>
> GLib's optionally non-fatal assertions add new traps, with much less
> excuse. Without recovery code, non-fatal assertions make little sense.
> But when you have to add recovery code anyway, you could easily switch
> to a new set of check functions, too. Overloading the existing
> assertion functions was in bad taste.
I agree that I wouldn't have named them _assert myself...
-- PMM
next prev parent reply other threads:[~2021-06-09 13:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-08 17:06 [PATCH] tests/unit/test-char.c: Fix error handling issues Peter Maydell
2021-06-08 19:51 ` Marc-André Lureau
2021-06-08 20:19 ` Peter Maydell
2021-06-09 12:36 ` Markus Armbruster
2021-06-09 13:19 ` Peter Maydell [this message]
2021-06-08 20:40 ` Daniel P. Berrangé
2021-06-08 20:33 ` Daniel P. Berrangé
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='CAFEAcA8DMwg5mAVDq8GJggCu79eNw6ZLKnbs0wFDPv=-VhhpSQ@mail.gmail.com' \
--to=peter.maydell@linaro.org \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=lvivier@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).