From: Eric Blake <eblake@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH] checkpatch: Disallow glib asserts in main code
Date: Fri, 28 Apr 2017 10:27:26 -0500 [thread overview]
Message-ID: <4259934c-58f5-16b2-4e24-6a3c926ef440@redhat.com> (raw)
In-Reply-To: <20170428151051.GH11415@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]
On 04/28/2017 10:10 AM, Daniel P. Berrange wrote:
>>> Or could we perhaps instead undo the damage via a hack like
>>>
>>> #define g_assert_cmpint g_assert_cmpint_orig
>>> #define g_assert_cmpint(x, y, z) \
>>> g_assert_cmpint_orig(x, y,x); \
>>> abort()
Not quite the right hack (we don't want to unconditionally abort, but
only when the condition fails).
>>
>> I'd be kind of OK adding a q_assert_cmpint if you wanted,
>> but I think we shouldn't change the semantics of a public
>> name.
I tend to agree there; having our own distinct name means that we can
see at a glance that our version will quit, no matter what the glib
version does.
>
> Personally I think it would be worth having them - the whole point of
> these more specific g_assert_* macros is that they provide clearer
> error messages when they're triggered, so I prefer their use generally
I agree that the improved error messages part is worthwhile. So maybe
we want:
#define q_assert_cmpint(x, y, z) \
do { \
g_assert_cmpint(x, y, z); \
assert(x y z); \
} while (0)
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
prev parent reply other threads:[~2017-04-28 15:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-27 16:55 [Qemu-devel] [PATCH] checkpatch: Disallow glib asserts in main code Dr. David Alan Gilbert (git)
2017-04-28 13:23 ` Paolo Bonzini
2017-04-28 13:34 ` Markus Armbruster
2017-04-28 13:46 ` Peter Maydell
2017-04-28 15:05 ` Eric Blake
2017-04-28 13:42 ` Daniel P. Berrange
2017-04-28 13:45 ` Dr. David Alan Gilbert
2017-04-28 15:10 ` Daniel P. Berrange
2017-04-28 15:27 ` Eric Blake [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=4259934c-58f5-16b2-4e24-6a3c926ef440@redhat.com \
--to=eblake@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=pbonzini@redhat.com \
--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 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).