All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: kwolf@redhat.com, aliguori@us.ibm.com, stefanha@gmail.com,
	qemu-devel@nongnu.org, pbonzini@redhat.com,
	Eric Blake <eblake@redhat.com>
Subject: Re: [Qemu-devel] [PATCH V2 2/6] libqblock type and structure defines
Date: Mon, 17 Sep 2012 10:23:12 +0800	[thread overview]
Message-ID: <50568990.6070409@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAAu8pHv8pR0efUg24h9VHWR0vN4aaCJJ=Sde0Mfn0AQNXACV8g@mail.gmail.com>

于 2012-9-15 2:11, Blue Swirl 写道:
> On Thu, Sep 13, 2012 at 3:49 AM, Eric Blake <eblake@redhat.com> wrote:
>> On 09/12/2012 09:33 PM, Eric Blake wrote:
>>>>   OK ,then I think
>>>> #if __GNUC__ >= 4
>>>> ....
>>>> #else
>>>>    [warn name space pollution may happen]
>>>> #endif
>>>> would be better.
>>>
>>> It may be shorter, but it is definitely not better, at least not in the
>>> current context of qemu.  Using the short form will fail a -Werror
>>> build, unless you also write a patch to qemu's configure to quit
>>> supplying -Wundef during builds.  But as touching configure has a bigger
>>> impact to the overall qemu project, you're going to need a lot more
>>> buy-in from other developers that -Wundef is not helping qemu gain any
>>> portability, and that it is safe to ditch it (or get enough
>>> counter-arguments from other developers why qemu insists on the
>>> anachronistic style enforced by -Wundef, at which point you must comply
>>> and use the longer form).
>>
>> On second thought, this _particular_ usage will never fail a -Wundef
>> -Werror build, precisely because -Wundef is a gcc warning, which impies
>> the warning is only ever useful in the same scenarios that the __GNUC__
>> macro is always defined (that is, __GNUC__ is undefined only on a
>> non-gcc compiler, but what non-gcc compiler supports -Wundef -Werror?).
>
> The library could be used by a project that does not use GCC or pick
> CFLAGS from QEMU configuration. Supporting for example MSVC or C++
> users for the library could be interesting one day, even if we didn't
> support MSVC or C++ at all for building the rest of QEMU.
>
   Each compiler would have its own predefined macro, so I think now
I can just support gcc and give a warning when gcc not found. If
more compiler is needed, extend the macro in the future.

>>
>> But why should this line be the one exemption to the rules?  Either qemu
>> insists on the -Wundef style of coding (and you should use the long form
>> to conform to that style, on the off-chance that someone ever wants to
>> port to a non-gcc compiler, even in this one place where gcc can't warn
>> you about the violation of that style), or we should change the qemu
>> style (at which point, the short form is nicer here, but it also implies
>> the potential for cleaning up lots of other places to also use short
>> forms and rely on preprocessor 0 computation).
>>
>> --
>> Eric Blake   eblake@redhat.com    +1-919-301-3266
>> Libvirt virtualization library http://libvirt.org
>>
>


-- 
Best Regards

Wenchao Xia

  reply	other threads:[~2012-09-17  2:23 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-10  8:26 [Qemu-devel] [PATCH V2 0/6] libqblock, qemu block layer library Wenchao Xia
2012-09-10  8:26 ` [Qemu-devel] [PATCH V2 1/6] libqblock API design Wenchao Xia
2012-09-10 21:07   ` Eric Blake
2012-09-11  3:16     ` Wenchao Xia
2012-09-14  2:03       ` Wenchao Xia
2012-09-11 20:28   ` Blue Swirl
2012-09-12  2:54     ` Wenchao Xia
2012-09-12  8:19     ` Kevin Wolf
2012-09-12  9:21       ` Wenchao Xia
2012-09-14 19:08       ` Blue Swirl
2012-09-10  8:26 ` [Qemu-devel] [PATCH V2 2/6] libqblock type and structure defines Wenchao Xia
2012-09-10 21:27   ` Eric Blake
2012-09-11  3:26     ` Wenchao Xia
2012-09-11  4:12       ` Eric Blake
2012-09-11 20:31   ` Blue Swirl
2012-09-11 22:52     ` Eric Blake
2012-09-12  3:05       ` Wenchao Xia
2012-09-12 12:59         ` Eric Blake
2012-09-13  3:24           ` Wenchao Xia
2012-09-13  3:33             ` Eric Blake
2012-09-13  3:49               ` Eric Blake
2012-09-14 18:11                 ` Blue Swirl
2012-09-17  2:23                   ` Wenchao Xia [this message]
2012-09-17 19:08                     ` Blue Swirl
2012-09-14 18:02       ` Blue Swirl
2012-09-10  8:26 ` [Qemu-devel] [PATCH V2 3/6] libqblock error handling Wenchao Xia
2012-09-10 21:33   ` Eric Blake
2012-09-11  4:36     ` Wenchao Xia
2012-09-11 20:32   ` Blue Swirl
2012-09-12  2:58     ` Wenchao Xia
2012-09-14 17:09       ` Blue Swirl
2012-09-10  8:26 ` [Qemu-devel] [PATCH V2 4/6] libqblock export some qemu block function Wenchao Xia
2012-09-10  8:26 ` [Qemu-devel] [PATCH V2 5/6] libqblock building system Wenchao Xia
2012-09-10  8:26 ` [Qemu-devel] [PATCH V2 6/6] libqblock test example Wenchao Xia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50568990.6070409@linux.vnet.ibm.com \
    --to=xiawenc@linux.vnet.ibm.com \
    --cc=aliguori@us.ibm.com \
    --cc=blauwirbel@gmail.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.