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

[Markus Armbruster]

Peter Maydell <address@hidden> writes:

> 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

Agreed on all counts.