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

[Markus Armbruster]

Andreas Färber <address@hidden> writes:

> Am 28.01.2013 22:10, schrieb Peter Maydell:
> [lengthy discussion of what may go wrong without do { ... } while (0)]
>
> We seem to to agree to disagree here.
>
> The use of an if (foo) { ... } inside Fred's macro (or my pseudocode?)
> was what prompted this whole mess, so there is no need to explain that
> to me.
>
> We seem to agree that by badly formulating a macro, bad effects can happen.
>
> Where we disagree is that you suggest that do { ... while (0) is any
> better than G_STMT_START ... G_STMT_END. I disagree and find *both*
> obscuring the code. I clearly stated why.

There's a significant difference: "do ... while (0)" is a C idiom, as
Peter pointed out.

> Therefore I am interested in a non-obscured solution!
>
> Analysing the reasons for the obscured suggestion:
>
> a) "if (foo) MACRO1(); else MACRO2();" is forbidden by Coding Style.
> Thus, if careful review indicates there are no such Coding Style
> violations, it is entirely possible not to add any
> fault-that-may-not-happen-obscuring macro statements.

Brittle.

> b) Working around an issue resulting from hiding C statements inside a
> preprocessor macro is totally backwards compared to properly using the C
> language in the first place. Its mechanism for reuse are functions, and
> for performance considerations static inline functions.

Nobody denies inline functions are to be preferred in many cases.

Valid exceptions include cases where we want genericity, which a macro
can easily provide, but an inline function can't.

> Therefore I disagree with you that b) is not an entirely different
> disussion as you repeatedly suggest and that according to a) it is not
> *generally* necessary to put do { ... } while (0) into any random macro
> that one writes. It depends on the contents and on the context.

I don't think Peter suggested to put do ... while (0) into random
macros!  He asked to put it exactly into *statement-like* macros, as per
standard C practice.  Most macros are expression-like.

> FWIW it is pretty similar to the reverse-comparison initiative: It is
> addressing an issue that I never run into and that Coding Style
> forbidding if ((foo = bar)) { ... } can address just as well, while
> keeping things more readable.

No, the true reason we frown on Yoda-comparisons is that they make the
code less readable without buying us anything!  The compiler is more
reliable at flagging comparison vs. assignment accidents than a style
convention could ever be at avoiding them.

>                               And that is from my perspective the core
> of this discussion: which solution is best *readable*, not what
> workaround *may* prevent some kind of error.
> Adding parenthesis to avoid operator precedence issues is much less
> invasive from my POV than adding two more lines with \ and indentation
> inside a macro.

I don't think the do ... while (0) safety guard makes these macros any
uglier than they already (and necessarily) are.  If you want pretty, use
an inline function.  If you must have a macro, and cannot bear "do
... while (0)", consider the GNU C extension for turning statements into
expressions: ({ ... }).

> BTW if this discussion were about how to write a single macro inside
> alpha code, there would be not much need for this discussion. KVM is
> using do { .. } while (0) already. This is about avoiding to
> unnecessarily *prescribe* cluttering every single source file in the
> tree as you seemed to suggest.

I think you're overstating your case.  Statement-like macros should be
rare.