From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH RFC tools 1/6] tools: Refactor "xentoollog"
 into its own library
Date: Tue, 22 Sep 2015 09:39:47 +0100
Message-ID: <1442911187.10338.109.camel@citrix.com>
References: <1433936188.30003.60.camel@citrix.com>
	<1433936205-21539-1-git-send-email-ian.campbell@citrix.com>
	<55796F0F.7040406@citrix.com>
	<22016.11647.190463.194074@mariner.uk.xensource.com>
	<5600385A.2060704@citrix.com>
	<22016.15007.372240.924416@mariner.uk.xensource.com>
	<56003ECD.9010105@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <56003ECD.9010105@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: roger.pau@citrix.com, wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On Mon, 2015-09-21 at 18:30 +0100, Andrew Cooper wrote:
> On 21/09/15 18:13, Ian Jackson wrote:
> > Andrew Cooper writes ("Re: [Xen-devel] [PATCH RFC tools 1/6] tools:
> > Refactor "xentoollog" into its own library"):
> > > On 21/09/15 17:17, Ian Jackson wrote:
> > > > Do you mean that statement expressions (originally a GNU extension)
> > > > should be avoided in tools code ?  A quick git-grep discovered that
> > > > xenctrl already contains numerous statement expressions.
> > > It is fine (in principle) to be used internally.  Not in a public
> > > header
> > > for what is supposed to be a clean API.
> > I don't understand why this distinction is relevant.  Either the
> > compiler supports it, or it doesn't.
> 
> There shouldn't be items in a public header which can't be used by all
> compilers which might want to compile it.
> 
> GCC is not the only compiler liable to encounter this new header file.
> 
[...]
> Please explain why you believe it to be unsuitable?  It is not perfect,
> but is far better than nothing.

It's a #define, so unless the including application actually uses it the
compiler proper (as opposed to cpp) will never see it.

Ian.