Peter Maydell <peter.mayd...@linaro.org> writes: > On 28 January 2013 19:14, Andreas Färber <afaer...@suse.de> wrote: >> Am 28.01.2013 19:59, schrieb Peter Maydell: >>> Er, what? "do ... while (0)" is completely standard practice >>> for writing robust macros in C. Patches which don't do that >>> should fail code review. >> >> Oh really? None of our QOM cast macros use it, they passed your review, >> and there is zero reason to bring that plague upon us for any reasonably >> small macro. > > Sorry, I didn't expand that fully because I thought it was > obvious that I didn't mean "apply this to every macro in QEMU". > To be clear: > > This is a standard practice for writing a robust macro, but > by "standard practice" I mean "putting in the do..while > in the places where the practice states that it is required", > not "wrapping every single #define in it even when that makes > no sense". > > Specifically, the loop is required where the macro: > 1. expands to several C statements, or a complex statement > like an "if" > 2. is used in a way that the user expects it to act like a > C function, ie as if it were a single C statement > > and the rationale is that it is easy for users to use such > a macro in contexts like > if (foo) > MY_MACRO(); > else > something; > > and get confusing errors or unintended behaviour. > (Yes, I know qemu's coding style would mandate braces; not all > our code has braces and in any case it is good defensive > programming practice to make the macro robust to minor > style issues in its users.) > > Therefore, when in QEMU we have macros which meet the > above conditions, we should follow this standard practice. > > The QOM cast macros do not meet condition 1 above > (they expand to a single simple expression). Nor does > memread(). These examples are therefore irrelevant to this > discussion. Other weird cases like macros which expand > to entire function definitions don't meet condition 2 because > they don't "look like" simple C functions, so they are also > not relevant here. > >> Anything larger in most use cases outside core TCG code is >> an overuse of macros. > > This is (again) a completely different discussion. If you want > to suggest that we should in general make more use of inline > functions rather than macros then yes, I agree with you. > All I am saying is that > 1. if and when we do use complex macros we need to get them right! > 2. we should do this in the standard way that would be recognised > by any C programmer who's dealt with the issue before, not > with bizarre glib specific macros which obscure what's actually > going on
Agreed on all counts.