qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 4/7] compiler: add macro for GCC weak symbols


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 4/7] compiler: add macro for GCC weak symbols
Date: Sat, 28 Jul 2012 08:52:25 +0000

On Sat, Jul 28, 2012 at 6:25 AM, Markus Armbruster <address@hidden> wrote:
> Anthony Liguori <address@hidden> writes:
>
>> Blue Swirl <address@hidden> writes:
>>
>>> On Fri, Jul 27, 2012 at 8:51 PM, Anthony Liguori <address@hidden> wrote:
>>>> If someone comes along and actively maintains support for another
>>>> compiler, we can revisit.  But otherwise, there's no practical reason to
>>>> avoid extensions.
>
> Exactly.
>
>>> Because it's more compliant to standards.
>>
>> That is not a benefit.  There is no practical advantage to sticking to
>> only C99.
>
> Agree.  "Compliance to X" is means, not ends.  Specifically, compliance
> to C99 is not a benefit by itself.  Portability to desirable targets is
> one.
>
> Right now, the code is portable enough for our current needs.  If you
> find a target you wish to support where it doesn't work, patches are
> welcome.
>
>> If we stuck to C99 only, QEMU would look very different.  We wouldn't
>> have type_init() so we wouldn't have the module system we use today.
>> It literally took me months to get those patches merged because Paul
>> made exactly the same argument you're making now.
>>
>> And it's really been one of the better cleanups in QEMU that we've ever
>> done (using modules to define devices).
>
> Developing is hard enough without tying ourselves into knots to avoid
> useful tools just because they haven't been blessed by the right
> standards committee.  Some pragmatism is in order.

IMHO it's just laziness to use easily avoidable constructs like ?:
without middle expression. In most cases (as can be seen in my patch),
you save typing and reviewing whopping 10-20 characters. We are in
seconds range of effort.

>
>>> There's also very little benefit from using the nonessential
>>> extensions.
>
> Blanket statement, needs evidence.
>
>> Using weak symbols eliminates #ifdefs and makes the code base a lot
>> cleaner.  It makes it easier to introduce architecture specific hooks in
>> a clean way.
>>
>> Considering how messy a lot of our target-specific code is, I think
>> there could be quite a significant benefit down the road.
>
> I don't have an informed opinion on this particular case.  All I can say
> here is patches are evidence.



reply via email to

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