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

[Blue Swirl]

On Tue, Jan 29, 2013 at 9:56 AM, Peter Maydell <address@hidden> wrote:
> 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

+1

>
> This really doesn't seem particularly complicated to me.
>
> -- PMM
>