qemu-devel
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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