On Tue, Jan 29, 2013 at 9:56 AM, Peter Maydell <peter.mayd...@linaro.org> wrote: > 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
+1 > > This really doesn't seem particularly complicated to me. > > -- PMM >