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
