On 29 January 2013 08:42, Andreas Färber <afaer...@suse.de> 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
