On 1/6/19 2:32 AM, Richard Henderson wrote: > On 1/6/19 11:38 AM, Eric Blake wrote: >> +/* >> + * Automatic type deduction, to be used as: >> + * QEMU_TYPEOF(expr) name = expr; >> + */ >> +#if QEMU_GNUC_PREREQ(4, 9) >> +# define QEMU_TYPEOF(a) __auto_type >> +#else >> +# define QEMU_TYPEOF(a) typeof(a) >> +#endif > > What's wrong with always using typeof? This seems like it leaves potential > odd > bugs affecting gcc-4.8.
Always using typeof is an option, but gcc documents that __auto_type is nicer than typeof: > Using '__auto_type' instead of 'typeof' has two advantages: > > * Each argument to the macro appears only once in the expansion of > the macro. This prevents the size of the macro expansion growing > exponentially when calls to such macros are nested inside arguments > of such macros. > > * If the argument to the macro has variably modified type, it is > evaluated only once when using '__auto_type', but twice if 'typeof' > is used. We don't use variably modified types (at least, I don't think we do), so the latter is moot (but WOULD be the spot where we are most likely to be bitten on 4.8 compilers lacking __auto_type); the former point is a minor speed win in favor of __auto_type. > >> +#undef MIN >> +#define MIN(a, b) \ >> + ({ \ >> + QEMU_TYPEOF((a) + 0) _a = (a) + 0; \ >> + QEMU_TYPEOF((b) + 0) _b = (b) + 0; \ > > If you're promoting the type, why don't you want to promote to the common type > between A and B? E.g. > > __typeof((a) + (b)) _a = (a), _b = (b); > > After all, that's what the result type of (p ? _a : _b) will be. That formulation should work as well, if anyone likes it better (but it does NOT work with __auto_type). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature