xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Egger <Christoph.Egger@amd.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH] libxl: Introduce LIBXL_DOMAIN_TYPE_INVALID to make gcc happy
Date: Fri, 18 May 2012 17:11:48 +0200	[thread overview]
Message-ID: <4FB666B4.4090807@amd.com> (raw)
In-Reply-To: <1337352958.22316.126.camel@zakaz.uk.xensource.com>

On 05/18/12 16:55, Ian Campbell wrote:

> On Fri, 2012-05-18 at 15:48 +0100, Dario Faggioli wrote:
>> On Fri, 2012-05-18 at 15:39 +0100, Ian Campbell wrote:
>>>> Which actually seems to be right:
>>>>
>>>> $ grep LIBXL_DOMAIN_TYPE_INVALID tools/* -R
>>>> tools/libxl/libxl_dm.c:    case LIBXL_DOMAIN_TYPE_INVALID:
>>>> tools/libxl/libxl_dm.c:    case LIBXL_DOMAIN_TYPE_INVALID:
>>>> tools/libxl/libxl_dom.c:        return LIBXL_DOMAIN_TYPE_INVALID;
>>>> tools/libxl/libxl_dom.c:        return LIBXL_DOMAIN_TYPE_INVALID;
>>>> tools/libxl/libxl.c:        case LIBXL_DOMAIN_TYPE_INVALID:
>>>>
>>>> Am I missing something?
>>>
>>> This should be defined in tools/libxl/libxl_types.idl but the patch
>>> doesn't seem to add it.
>>>
>> Yep, I'm adding it myself with the attached patch, but I'm now getting
>> this:
>>
>> _libxl_types.c: In function ‘libxl_domain_build_info_dispose’:
>> _libxl_types.c:91:5: error: enumeration value ‘LIBXL_DOMAIN_TYPE_INVALID’ not handled in switch [-Werror=switch]
>> _libxl_types.c: In function ‘libxl_domain_build_info_init_type’:
>> _libxl_types.c:284:5: error: enumeration value ‘LIBXL_DOMAIN_TYPE_INVALID’ not handled in switch [-Werror=switch]
>> testidl.c: In function ‘libxl_domain_build_info_rand_init’:
>> testidl.c:366:5: error: enumeration value ‘LIBXL_DOMAIN_TYPE_INVALID’ not handled in switch [-Werror=switch]
>> _libxl_types.c: In function ‘libxl_domain_build_info_gen_json’:
>> _libxl_types.c:1713:5: error: enumeration value ‘LIBXL_DOMAIN_TYPE_INVALID’ not handled in switch [-Werror=switch]
>> cc1: all warnings being treated as errors
>>
>> :-O
> 
> I wonder if just changing the return type of libxl__domain_type to int
> would be better than this? I guess it'll probably be much the same.


Is libxl_domain_type part of the API ? If yes then it is better to use
'int' and change the enum to #defines to be safe side. An enum used
in the API has a backward-compatibility issue related to its size:

An enum is as small as possible to hold the largest value.
Whatever 'as small as possible' means depends on the architecture.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  parent reply	other threads:[~2012-05-18 15:11 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-18 11:24 libxl: build failure due to 'libxl_domain_type' Christoph Egger
2012-05-18 12:21 ` [PATCH] libxl: Introduce LIBXL_DOMAIN_TYPE_INVALID to make gcc happy Christoph Egger
2012-05-18 14:30   ` Dario Faggioli
2012-05-18 14:39     ` Ian Campbell
2012-05-18 14:48       ` Dario Faggioli
2012-05-18 14:55         ` Ian Campbell
2012-05-18 15:07           ` Dario Faggioli
2012-05-22 10:16             ` Ian Campbell
2012-05-22 14:58               ` Dario Faggioli
2012-05-22 15:07                 ` Ian Campbell
2012-05-22 16:18                   ` Dario Faggioli
2012-05-23  8:59                     ` Christoph Egger
2012-05-23  9:23                       ` Dario Faggioli
2012-05-23  9:30                         ` Christoph Egger
2012-05-18 15:11           ` Christoph Egger [this message]
2012-05-18 15:22             ` Ian Campbell
2012-05-23 10:53           ` Ian Jackson
2012-05-23 11:17             ` Dario Faggioli
2012-05-23 12:37               ` Ian Jackson
2012-05-23 12:49                 ` Dario Faggioli
2012-05-23 13:12                   ` Dario Faggioli
2012-05-23 13:47                     ` Christoph Egger
2012-05-23 14:36                   ` Ian Jackson
2012-05-23 15:21                     ` Dario Faggioli

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=4FB666B4.4090807@amd.com \
    --to=christoph.egger@amd.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=raistlin@linux.it \
    --cc=xen-devel@lists.xen.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).