From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: [PATCH V5 19/32] libxl/gentypes.py: don't generate default values Date: Tue, 20 May 2014 18:17:43 +0100 Message-ID: <20140520171743.GA21047@zion.uk.xensource.com> References: <1400018054-26038-1-git-send-email-wei.liu2@citrix.com> <1400018054-26038-20-git-send-email-wei.liu2@citrix.com> <1400592549.6946.49.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1400592549.6946.49.camel@kazak.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: ian.jackson@eu.citrix.com, Wei Liu , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Tue, May 20, 2014 at 02:29:09PM +0100, Ian Campbell wrote: > On Tue, 2014-05-13 at 22:54 +0100, Wei Liu wrote: > > If a type has init_val defined and a field of the type has the value of > > init_val, there's no need to generate output for that field. > > Please can you explain why there is no need. And I think you need to > mention JSON here somewhere. > Sure. "If a type has init_val defined and a field of the type has the value of init_val, there's no need to generate output for that field in JSON output. When the parser consumes that generated JSON object, all default values should be automatically filled in." > > Also define a bunch of init_vals for enumeration types. > > I'm not convinced by this. If a type has no initval then you should > compare it to zero, which is a valid thing to do even for an enum. > What I really did here for enum type was to replace magic number 0 (or any other predefined value) with a meaningful macro, so that the generated code can have if (FOO == LIBXL_FOO_DEFAULT) other than if (FOO == 0) which has better readability. > NB you changed the init_val for some typesto (e.g. from 1 to > LIBXL_VGA_INTERFACE_TYPE_CIRRUS), which is a no semantic change change, > but did mean I had to double check. > Corret, I didn't intend to make any semantic changes. Wei.