qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Eric Blake <eblake@redhat.com>, qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
	Alberto Garcia <berto@igalia.com>, Kevin Wolf <kwolf@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 1/6] qapi: Add qobject_to()
Date: Mon, 22 Jan 2018 17:53:58 +0100	[thread overview]
Message-ID: <db14dd01-2a01-8ab3-d4b6-bf1a46425eef@redhat.com> (raw)
In-Reply-To: <39ad6e43-024c-6384-d014-e0b8f83ed3a7@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 3125 bytes --]

On 2018-01-22 16:33, Eric Blake wrote:
> On 01/20/2018 09:44 AM, Max Reitz wrote:
>> This is a dynamic casting macro that, given a QObject type, returns an
>> object as that type or NULL if the object is of a different type (or
>> NULL itself).
>>
>> The macro uses lower-case letters because:
>> 1. There does not seem to be a hard rule on whether qemu macros have to
>>    be upper-cased,
>> 2. The current situation in qapi/qmp is inconsistent (compare e.g.
>>    QINCREF() vs. qdict_put()),
>> 3. qobject_to() will evaluate its @obj parameter only once, thus it is
>>    generally not important to the caller whether it is a macro or not,
>> 4. I prefer it aesthetically.
>>
>> Signed-off-by: Max Reitz <mreitz@redhat.com>
>> ---
>> You're more than welcome to convince me to call it QOBJECT_TO()!
> 
> I can live with the lower-case version; especially with your good list
> of reasons for it ;)
> 
>> ---
>>  include/qapi/qmp/qobject.h | 32 ++++++++++++++++++++++++++++++++
>>  1 file changed, 32 insertions(+)
>>
>> diff --git a/include/qapi/qmp/qobject.h b/include/qapi/qmp/qobject.h
>> index 38ac68845c..1211989ca0 100644
>> --- a/include/qapi/qmp/qobject.h
>> +++ b/include/qapi/qmp/qobject.h
>> @@ -50,6 +50,24 @@ struct QObject {
>>  #define QDECREF(obj)              \
>>      qobject_decref(obj ? QOBJECT(obj) : NULL)
>>  
>> +/* Required for qobject_to() */
>> +#define QTYPE_CAST_TO_QNull     QTYPE_QNULL
>> +#define QTYPE_CAST_TO_QNum      QTYPE_QNUM
>> +#define QTYPE_CAST_TO_QString   QTYPE_QSTRING
>> +#define QTYPE_CAST_TO_QDict     QTYPE_QDICT
>> +#define QTYPE_CAST_TO_QList     QTYPE_QLIST
>> +#define QTYPE_CAST_TO_QBool     QTYPE_QBOOL
>> +
>> +#ifdef CONFIG_STATIC_ASSERT
>> +_Static_assert(QTYPE__MAX == 7,
>> +               "The QTYPE_CAST_TO_* list needs to be extended");
>> +#endif
> 
> Why not use QEMU_BUILD_BUG_ON() instead of _Static_assert?  That way,
> this check will break the build even on older compilers that lack
> _Static_assert but where we still know how to trigger a build failure.

One reason would be because _Static_assert() allows me to give a nice
warning message -- I could add a comment above the QEMU_BUILD_BUG_ON()
line and hope for the best, but still, I like that better.

The other is that I assumed most people would be using C11 compilers
now, so the omission would be spotted sufficiently early.
"Sufficiently" because it's actually not that bad for this list to be
incomplete.  The worst is that you can't use qobject_to() for your
desired target type, but that's hardly catastrophic.

I could add an #else branch with QEMU_BUILD_BUG_ON().  Or I could add a
QEMU_BUILD_BUG_MSG() macro that takes a message (which is omitted if you
don't have _Static_assert() but would still make for a nice comment).  I
guess the latter would be a nice idea in general...?

Max

>> +
>> +#define qobject_to(obj, type) \
>> +    container_of(qobject_check_type(obj, glue(QTYPE_CAST_TO_, type)) ?: \
>> +                     QOBJECT((type *)NULL), \
>> +                 type, base)
> 
> Slick!
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

  reply	other threads:[~2018-01-22 16:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-20 15:44 [Qemu-devel] [PATCH v2 0/6] block: Handle null backing link Max Reitz
2018-01-20 15:44 ` [Qemu-devel] [PATCH v2 1/6] qapi: Add qobject_to() Max Reitz
2018-01-22 15:33   ` Eric Blake
2018-01-22 16:53     ` Max Reitz [this message]
2018-01-31 16:02   ` Alberto Garcia
2018-01-20 15:44 ` [Qemu-devel] [PATCH v2 2/6] qapi: Replace qobject_to_X(o) by qobject_to(o, X) Max Reitz
2018-01-31 16:05   ` Alberto Garcia
2018-01-31 16:11   ` Eric Blake
2018-01-31 16:14     ` Eric Blake
2018-01-20 15:44 ` [Qemu-devel] [PATCH v2 3/6] qapi: Remove qobject_to_X() functions Max Reitz
2018-01-31 16:05   ` Alberto Garcia
2018-01-20 15:44 ` [Qemu-devel] [PATCH v2 4/6] qapi: Make more of qobject_to() Max Reitz
2018-01-31 16:16   ` Alberto Garcia
2018-01-20 15:44 ` [Qemu-devel] [PATCH v2 5/6] block: Handle null backing link Max Reitz
2018-02-01 14:17   ` Alberto Garcia
2018-01-20 15:44 ` [Qemu-devel] [PATCH v2 6/6] block: Deprecate "backing": "" Max Reitz
2018-01-31 16:22   ` Eric Blake
2018-02-01 14:18   ` Alberto Garcia

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=db14dd01-2a01-8ab3-d4b6-bf1a46425eef@redhat.com \
    --to=mreitz@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berto@igalia.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.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 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).