From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] libxl: Introduce LIBXL_DOMAIN_TYPE_INVALID to make gcc happy Date: Tue, 22 May 2012 18:18:13 +0200 Message-ID: <1337703493.27368.18.camel@Solace> References: <4FB63171.3020102@amd.com> <4FB63EB6.10803@amd.com> <1337351445.16815.19.camel@Solace> <1337351979.22316.123.camel@zakaz.uk.xensource.com> <1337352492.16815.22.camel@Solace> <1337352958.22316.126.camel@zakaz.uk.xensource.com> <1337353667.16815.25.camel@Solace> <1337681771.10118.69.camel@zakaz.uk.xensource.com> <1337698697.20890.5.camel@Abyss> <1337699271.10118.140.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7212157207612942622==" Return-path: In-Reply-To: <1337699271.10118.140.camel@zakaz.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 Campbell Cc: Christoph Egger , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============7212157207612942622== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-9IqIBB53Vs9ZQUxjw29P" --=-9IqIBB53Vs9ZQUxjw29P Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-05-22 at 16:07 +0100, Ian Campbell wrote: > > > I did, I guess we need to check that all callers can cope with this n= ew > > > return value though? > > >=20 > > Sure, that was only to be sure I got what you were saying. :-) > >=20 > > What I'm not getting right now is whether or not a proper patch doing > > such is still interesting or not? Also, how come am I almost the only > > one seeing that issue? Does it relate to gcc version? :-O >=20 > There's been a handful of other reports this week. It does seem to be to > do with gcc version, yes. >=20 Ok then, I didn't notice that. I went through the callers and they seem to be fine with the change, as the return type of the function is pretty much always converted to the enum (i.e., libxl_domain_type) and used in a switch with a proper 'default' clause, in case they care about something different from _HVM or _PV. So, the below is what I'm using to build (and run) these days... Or was it something different that you meant when saying "check that all callers can cope with this" ? (I can repost as a separate mail if wanted) Dario 8<--------------------------- libxl: make libxl__domain_type return 'int' To avoid gcc > 4.6.3 complaining about: libxl.c: In function =E2=80=98libxl_primary_console_exec=E2=80=99: libxl.c:1233:9: error: case value =E2=80=984294967295=E2=80=99 not in enume= rated type =E2=80=98libxl_domain_type=E2=80=99 [-Werror=3Dswitch] Callers have been checked and are fine with the change. Signed-off-by: Dario Faggioli diff -r 6dc80df50fa8 tools/libxl/libxl_dom.c --- a/tools/libxl/libxl_dom.c Tue May 22 16:30:11 2012 +0200 +++ b/tools/libxl/libxl_dom.c Tue May 22 18:06:41 2012 +0200 @@ -25,7 +25,7 @@ =20 #include "libxl_internal.h" =20 -libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid) +int libxl__domain_type(libxl__gc *gc, uint32_t domid) { libxl_ctx *ctx =3D libxl__gc_owner(gc); xc_domaininfo_t info; diff -r 6dc80df50fa8 tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Tue May 22 16:30:11 2012 +0200 +++ b/tools/libxl/libxl_internal.h Tue May 22 18:06:41 2012 +0200 @@ -714,7 +714,7 @@ int libxl__self_pipe_eatall(int fd); /*=20 =20 =20 /* from xl_dom */ -_hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid= ); +_hidden int libxl__domain_type(libxl__gc *gc, uint32_t domid); _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid); _hidden int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_s= ched_params *scparams); #define LIBXL__DOMAIN_IS_TYPE(gc, domid, type) \ --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-9IqIBB53Vs9ZQUxjw29P Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+7vEUACgkQk4XaBE3IOsTbZwCdGEecAF9c8wdi98EC6+fD8aze HKYAnjtXaVQeChUyEdmDHfsIf7oek5rJ =XNCd -----END PGP SIGNATURE----- --=-9IqIBB53Vs9ZQUxjw29P-- --===============7212157207612942622== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7212157207612942622==--