Am 28.01.2013 19:59, schrieb Peter Maydell:
> On 28 January 2013 18:54, Andreas Färber <afaer...@suse.de> wrote:
>> Am 28.01.2013 19:22, schrieb Richard Henderson:
>>> On 01/27/2013 05:32 AM, Andreas Färber wrote:
>>>> +#define LOG_DISAS(...) G_STMT_START \
>>>> + if (ALPHA_DEBUG_DISAS) { \
>>>> + qemu_log_mask(CPU_LOG_TB_IN_ASM, ## __VA_ARGS__); \
>>>> + } \
>>>> + G_STMT_END
>>>
>>> I see zero advantage to using G_STMT_START/END over the
>>> shorter and significantly more obvious direct use of do/while.
>>
>> Well, I see close to zero advantage in using a loop at all.
>
> 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. Anything larger in most use cases outside core TCG code is
an overuse of macros.
Misusing the memread() macros for instance gives you weird compiler
messages simply because it is in fact seeing qtest_memread() instead
with 1-shifted arguments. Those should be static inline functions
accessing a global variable IMO.
I simply didn't think of va_list here when hacking this RFC together.
Andreas
>> An inline function by comparison would relieve us from
>> all that \ ugliness, too.
>
> This is a completely separate argument.
> 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
>
> -- PMM
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
