From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH RFC tools 1/6] tools: Refactor "xentoollog" into its own library Date: Mon, 21 Sep 2015 18:30:53 +0100 Message-ID: <56003ECD.9010105@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <22016.15007.372240.924416@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: roger.pau@citrix.com, wei.liu2@citrix.com, Ian Campbell , stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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. > >>>> violates several principles of least supprise, >>> This is just invective. >> /me googles and discovered a new word. I stand by my statement. > Well, if you feel so strongly, I won't object to a patch to remove it. This is exactly why I raise the point now when the ABI is deliberately changing. Having said that, it was previously in libxc so anything went. I would be happy to submit a patch either to libxc now, or to libxentoollog later. > >>>> As part of the tidyup, we should choose a particular C standard (89, >>>> probably) and ensure that the API/ABI complies with `gcc -std=c$VER >>>> -pedantic`. This will help to provide a consistent API on other >>>> platforms (I seem to recall an effort to port libvchan to windows.) >>> -pedantic is certainly a bad idea. >> Pedantic is absolutely the correct answer. It will cause gcc to reject >> any non C compliant statements. > No, that is not what -pedantic does. Please RTFM. Please explain why you believe it to be unsuitable? It is not perfect, but is far better than nothing. ~Andrew