qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/14] More #include cleanups


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 00/14] More #include cleanups
Date: Tue, 9 Feb 2016 11:29:31 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

On 02/09/2016 11:04 AM, Peter Maydell wrote:

>>> So _something_ in osdep.h is redefining 'inline' with disastrous effects
>>> to C++.
>>
>> This hack seems to fix things; but I'm not enough of a C++ expert to
>> know if it is the best fix.
>>
>> diff --git i/include/qemu/compiler.h w/include/qemu/compiler.h
>> index d22eb01..d50b806 100644
>> --- i/include/qemu/compiler.h
>> +++ w/include/qemu/compiler.h
>> @@ -77,6 +77,7 @@
>>  #define typeof_field(type, field) typeof(((type *)0)->field)
>>  #define type_check(t1,t2) ((t1*)0 - (t2*)0)
>>
>> +#ifndef __cplusplus
>>  #ifndef always_inline
>>  #if !((__GNUC__ < 3) || defined(__APPLE__))
>>  #ifdef __OPTIMIZE__
>> @@ -88,6 +89,7 @@
>>  #undef inline
>>  #define inline always_inline
>>  #endif
>> +#endif
> 
> Ah, well tracked down. I guess my system headers don't happen
> to rely on this bit of inline syntax.
> 
> Next question -- do we really need to redefine "inline" to
> always_inline at all, in C or C++? (cc'd a few people who might
> have an opinion). My instinct is to say "don't do this, just
> trust the compiler to decide whether to bother inlining".

If ripping that chunk out doesn't hurt anything, I'm all in favor of it.
Redefining 'inline' tends to hurt more than it prevents (and while there
IS the case of C89 vs. C99 vs. GNU having different semantics for
'static inline', those are best worked around by writing and
consistently using wrapper macros such as 'STATIC_INLINE', not
redefining 'inline' itself).

> 
> Git blame says this was added back in commit df2542c737ea2 in
> 2007, with the rationale "To avoid discarded inlining bug"...

The date alone says it may be time to quit doing it :)

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]