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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to