xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, Julien Grall <julien.grall@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>,
	Wei.Liu2@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof
Date: Wed, 7 Oct 2015 09:28:18 +0100	[thread overview]
Message-ID: <1444206498.5302.259.camel@citrix.com> (raw)
In-Reply-To: <5614D86302000078000A8D8E@prv-mh.provo.novell.com>

On Wed, 2015-10-07 at 00:31 -0600, Jan Beulich wrote:
> > > > On 06.10.15 at 19:25, <julien.grall@citrix.com> wrote:
> > On 05/10/15 11:31, Jan Beulich wrote:
> > > > > > On 04.10.15 at 21:24, <julien.grall@citrix.com> wrote:
> > > > The keyword typeof is not portable:
> > > > 
> > > > /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit
> > > > declaration
> > > > of function 'typeof' is invalid in C99
> > > > [-Werror,-Wimplicit-function-declaration]
> > > 
> > > Actually, it's worse than that - typeof() is a gcc extension, and we
> > > shouldn't use extensions in public headers without at least having
> > > alternative code for not gcc compatible compilers in place. In fact
> > > we should probably aim at removing the exclusion of public/arch-%
> > > in the ANSI conformance check; IIRC I had to add it because things
> > > wouldn't build without, but with the (then forgotten) goal of dealing
> > > with this properly later on.
> > 
> > I don't see how header.chk would have catch my issue. The problem is in
> > the macro set_xen_guest_handle_raw which is not used within the headers
> > (except by set_xen_guest_handle which is not used at all).
> > 
> > It may be worth to add a dummy .c which call the macros to check they
> > are ANSI compliant.
> 
> Hmm, true, conformance of macros isn't being checked right now
> (i.e. we only verify that the header as such compiles, not that
> everything in the header can be used). A manually created source
> would help only to some degree, as it would need to be kept up to
> date with future additions. I.e. the long term solution probably
> ought to be an at least partially machine generated source file

It ought to be possible to at least automatically check that every
    #define ([A-Za-z_]+)
is matched by a corresponding $1 in the .c file.

> . I added this to my todo list (but towards the end of it).

FWIW I have a similar issue with the headers checks for my split up
libxenctrl stable libraries series, and it is in a similar place on my todo
list...

Ian.

  reply	other threads:[~2015-10-07  8:38 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-04 19:24 [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof Julien Grall
2015-10-05 10:31 ` Jan Beulich
2015-10-06 17:25   ` Julien Grall
2015-10-07  6:31     ` Jan Beulich
2015-10-07  8:28       ` Ian Campbell [this message]
2015-10-05 13:40 ` Wei Liu
2015-10-06  9:43   ` Julien Grall
2015-10-23 13:13 ` Julien Grall
2015-10-23 13:30   ` Ian Campbell
2015-10-23 13:52     ` Jan Beulich
2015-10-23 13:58       ` Julien Grall
2015-10-23 14:16         ` Jan Beulich
2015-10-23 14:31           ` Ian Campbell
2015-10-23 14:35             ` Ian Campbell
2015-10-23 14:37             ` Jan Beulich
2015-10-23 14:44               ` Julien Grall
2015-10-23 14:55                 ` Ian Campbell
2015-10-23 15:11                   ` Jan Beulich
2015-10-26 18:08                   ` Julien Grall
2015-10-27  8:05                     ` Jan Beulich
2015-10-28 15:44                       ` Julien Grall
2015-10-28 15:52                         ` Jan Beulich
2015-10-29 11:40                           ` Stefano Stabellini
2015-10-27  8:07                     ` Jan Beulich
2015-10-27 10:20                       ` Julien Grall
2015-10-23 14:03       ` Ian Campbell
2015-10-23 14:24         ` Jan Beulich
2015-10-23 14:48           ` Ian Campbell
2015-10-23 14:55             ` Jan Beulich

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=1444206498.5302.259.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=Wei.Liu2@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=julien.grall@citrix.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).