Re: [Qemu-devel] [RFC 10/19] target-alpha: Refactor debug output macros

[Peter Maydell]

On 28 January 2013 19:14, Andreas Färber <address@hidden> wrote:
> Am 28.01.2013 19:59, schrieb Peter Maydell:
>> Er, what? "do ... while (0)" is completely standard practice
>> for writing robust macros in C. Patches which don't do that
>> should fail code review.
>
> Oh really? None of our QOM cast macros use it, they passed your review,
> and there is zero reason to bring that plague upon us for any reasonably
> small macro.

Sorry, I didn't expand that fully because I thought it was
obvious that I didn't mean "apply this to every macro in QEMU".
To be clear:

This is a standard practice for writing a robust macro, but
by "standard practice" I mean "putting in the do..while
in the places where the practice states that it is required",
not "wrapping every single #define in it even when that makes
no sense".

Specifically, the loop is required where the macro:
 1. expands to several C statements, or a complex statement
    like an "if"
 2. is used in a way that the user expects it to act like a
    C function, ie as if it were a single C statement

and the rationale is that it is easy for users to use such
a macro in contexts like
 if (foo)
     MY_MACRO();
 else
     something;

and get confusing errors or unintended behaviour.
(Yes, I know qemu's coding style would mandate braces; not all
our code has braces and in any case it is good defensive
programming practice to make the macro robust to minor
style issues in its users.)

Therefore, when in QEMU we have macros which meet the
above conditions, we should follow this standard practice.

The QOM cast macros do not meet condition 1 above
(they expand to a single simple expression). Nor does
memread(). These examples are therefore irrelevant to this
discussion. Other weird cases like macros which expand
to entire function definitions don't meet condition 2 because
they don't "look like" simple C functions, so they are also
not relevant here.

> Anything larger in most use cases outside core TCG code is
> an overuse of macros.

This is (again) a completely different discussion. If you want
to suggest that we should in general make more use of inline
functions rather than macros then yes, I agree with you.
All I am saying is that
 1. if and when we do use complex macros we need to get them right!
 2. we should do this in the standard way that would be recognised
    by any C programmer who's dealt with the issue before, not
    with bizarre glib specific macros which obscure what's actually
    going on

-- PMM