qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 08/18] qdict qlist: Make most helper macros func


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 08/18] qdict qlist: Make most helper macros functions
Date: Wed, 31 Jan 2018 09:11:24 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Eric Blake <address@hidden> writes:

> On 01/30/2018 04:21 AM, Markus Armbruster wrote:
>> The macro expansions of qdict_put_TYPE() and qlist_append_TYPE() need
>> qbool.h, qnull.h, qnum.h and qstring.h to compile.  We include qnull.h
>> and qnum.h in the headers, but not qbool.h and qstring.h.  Works,
>> because we include those wherever the macros get used.
>> 
>> Open-coding these helpers is of dubious value.  Turn them into
>> functions and drop the includes from the headers.
>> 
>> This cleanup makes the number of objects depending on qapi/qmp/qnum.h
>> from 4548 (out of 4739) to 46 in my "build everything" tree.  For
>> qapi/qmp/qnull.h, the number drops from 4549 to 21.
>
> Impressive!
>
>
>> +++ b/qobject/qdict.c
>> @@ -14,6 +14,7 @@
>>  #include "qapi/qmp/qnum.h"
>>  #include "qapi/qmp/qdict.h"
>>  #include "qapi/qmp/qbool.h"
>> +#include "qapi/qmp/qnull.h"
>>  #include "qapi/qmp/qstring.h"
>>  #include "qapi/qmp/qobject.h"
>>  #include "qapi/error.h"
>> @@ -143,6 +144,26 @@ void qdict_put_obj(QDict *qdict, const char *key, 
>> QObject *value)
>>      }
>>  }
>>  
>> +void qdict_put_int(QDict *qdict, const char *key, int64_t value)
>> +{
>> +    qdict_put(qdict, key, qnum_from_int(value));
>> +}
>
> If I'm not mistaken (although I didn't actually test), this triggers a
> false positive in scripts/coccinelle/qobject.cocci, no?  Is there a
> convenient way to tell coccinelle that a rewrite pattern applies
> everywhere except for where the pattern itself is implemented?  But even

I figure it's possible, but too much trouble to be worthwhile.

> if not, we can always use manual inspection when rerunning Coccinelle to
> make sure we don't turn these into infinite loops.

Yup.

> Reviewed-by: Eric Blake <address@hidden>

Thanks!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]