qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] [RFC 10/19] target-alpha: Refactor debug output macros
Date: Tue, 29 Jan 2013 09:56:15 +0000

On 29 January 2013 08:42, Andreas Färber <address@hidden> wrote:
> Am 28.01.2013 22:10, schrieb Peter Maydell:
> 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.P
>
> Therefore I am interested in a non-obscured solution!

There is none if you want to use a multistatement macro
(which presumably you do because that's what your patch does).
The best you can do is "standard thing that has been done for
decades and that is easily recognisable".

> 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.

This requires analysis of all the callsites (including any that
may be incoming in not-yet-applied patchsets) -- that's a lot
harder and more error prone than just getting the macro right
in the first place.

> 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.
>
> Therefore I disagree with you that b) is not an entirely different
> disussion as you repeatedly suggest

It clearly is, because *you didn't submit a patch using an inline
function*. The whole reason we're having this argument is that you
submitted a patch that uses a multistatement macro. Feel free
to resubmit something using an inline function if you like. Once
again:

 C macro with do..while(0): OK
 inline function: also OK
 C macro missing do..while(0) protection: not OK
 C macro using glib obfuscated macros: also not OK

This really doesn't seem particularly complicated to me.

-- PMM



reply via email to

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