Re: [Qemu-devel] [PATCH v2 2/3] qobject: introduce QObjectCommon

[Marc-André Lureau]

Hi

On Wed, Mar 28, 2018 at 3:45 PM, Eric Blake <address@hidden> wrote:
> On 03/28/2018 08:07 AM, Marc-André Lureau wrote:
>>
>> By moving the common fields to a QObjectCommon, QObject can be a type
>> which also has a 'base' QObjectCommon field. This allows to write a
>> generic QOBJECT() macro that will work with any QObject type,
>> including QObject itself. The container_of() macro ensures that the
>> object to cast has a QObjectCommon base field, give me some type
>> safety guarantees. However, for it to work properly, all QObject types
>> must have 'base' at offset 0 (which is ensured by static checking from
>> previous patch)
>>
>> Signed-off-by: Marc-André Lureau <address@hidden>
>> ---
>
>
>> +++ b/include/qapi/qmp/qbool.h
>> @@ -17,7 +17,7 @@
>>   #include "qapi/qmp/qobject.h"
>>     struct QBool {
>> -    QObject base;
>> +    struct QObjectCommon base;
>
>
> Why no 'typedef struct QObjectCommon QObjectCommon' in scope to make this
> simpler?

We could (not having the typedef enforces the feeling that
QObjectCommon is internal in my mind, but ymmv)

>> -/* Get the 'base' part of an object */
>> -#define QOBJECT(obj) (&(obj)->base)
>> +struct QObject {
>> +    struct QObjectCommon base;
>> +};
>> +
>> +#define QOBJECT(x) \
>> +   container_of(&(x)->base, QObject, base)
>
>
> If I understand correctly, this still causes clang complaints when called as
> QOBJECT(NULL).  As long as we are touching this, should we improve this
> macro to be friendly to NULL conversion?

I don't see much need for allowing NULL (literally) to be passed to
QOBJECT(). If it's a null pointer, as long as it has the right type,
it should be fine, shouldn't it?

> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org