[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH V3 2/7] virtio-bus: introduce virtio-bus
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH V3 2/7] virtio-bus: introduce virtio-bus |
Date: |
Mon, 21 Jan 2013 11:40:18 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
On 01/21/2013 11:05 AM, Peter Maydell wrote:
> On 21 January 2013 17:56, Eric Blake <address@hidden> wrote:
>> On 01/21/2013 08:48 AM, Peter Maydell wrote:
>>> On 14 January 2013 23:08, <address@hidden> wrote:
>>>> +#define TYPE_VIRTIO_BUS "virtio-bus"
>>>> +#define VIRTIO_BUS_GET_CLASS(obj) \
>>>> + OBJECT_GET_CLASS(VirtioBusClass, obj, TYPE_VIRTIO_BUS)
>>>> +#define VIRTIO_BUS_CLASS(klass) \
>>>> + OBJECT_CLASS_CHECK(VirtioBusClass, klass, TYPE_VIRTIO_BUS)
>>>
>>> 'obj' and 'klass' need brackets round them, because they're
>>> macro arguments.
>>
>> Brackets are only necessary if the C parser could misinterpret things
>> without the brackets; but in this particular case, there is no ambiguity
>> (unless OBJECT_GET_CLASS() and OBJECT_CLASS_CHECK() are improperly
>> under-parenthesized).
>
> Yes, but "we can get away without parens here because we know
> that other macro over there has parens in it" is unnecessarily
> tricky in my opinion.
The rule of thumb for when to use parentheses in macros should generally
be: can the caller ever pass a series of tokens which would cause a
different parse than a single token; likewise, can the macro expand to
more than one token where the expansion no longer behaves like a single
function call. If so, then we are burdening the caller with the need to
use parenthesis, and the macro is a potential bug. If not, then the
parenthesis are redundant.
For something like '#define foo(x) x++', we can demonstrate that passing
*a' leads to '*a++', which has a different meaning than '(*a)++'. Thus,
that macro has a bug unless written '#define foo(x) ((x)++)'.
But for argument lists, there is nothing the user can pass that can
cause the parser to get confused on the end of the argument list; even
if the user passes more than one token to the parameter 'obj', there is
no way that VIRTIO_BUS_GET_CLASS(*function_to_give_obj()) expanding to
OBJECT_GET_CLASS(VirtioBusClass, *function_to_give_obj(),
TYPE_VIRTIO_BUS) can be parsed differently than
OBJECT_GET_CLASS(VirtioBusClass, (*function_to_give_obj()),
TYPE_VIRTIO_BUS), so the extra parentheses would be redundant in the
definition of VIRTIO_BUS_GET_CLASS.
But if you insist on a rule of thumb that all macro arguments are always
parenthesized, even when not strictly necessary, because it makes for
less thinking when writing the macro, I'm not going to complain.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] [PATCH V3 3/7] virtio-device: refactor virtio-device., fred . konrad, 2013/01/14
[Qemu-devel] [PATCH V3 4/7] virtio-pci-bus: introduce virtio-pci-bus., fred . konrad, 2013/01/14
[Qemu-devel] [PATCH V3 6/7] virtio-s390-bus: add virtio-s390-bus., fred . konrad, 2013/01/14
[Qemu-devel] [PATCH V3 5/7] virtio-pci: refactor virtio-pci device., fred . konrad, 2013/01/14
[Qemu-devel] [PATCH V3 7/7] virtio-s390-device: create a virtio-s390-bus during init., fred . konrad, 2013/01/14
Re: [Qemu-devel] [PATCH V3 0/7] Virtio-refactoring part1., Anthony Liguori, 2013/01/21