Hi
On Wed, Mar 28, 2018 at 3:45 PM, Eric Blake <[email protected]> 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 <[email protected]>
>> ---
>
>
>> +++ 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
