From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony PERARD <anthony.perard@citrix.com>
Subject: Re: [PATCH V4 09/24] libxl_json: introduce parser
 functions for builtin types
Date: Tue, 13 May 2014 12:28:42 +0100
Message-ID: <20140513112842.GA2215@perard.uk.xensource.com>
References: <20140506154220.GS17067@zion.uk.xensource.com>
	<20140512164313.GF6332@zion.uk.xensource.com>
	<1399969566.11314.20.camel@kazak.uk.xensource.com>
	<20140513091954.GG6332@zion.uk.xensource.com>
	<1399973577.11314.35.camel@kazak.uk.xensource.com>
	<20140513104004.GH6332@zion.uk.xensource.com>
	<1399977904.21867.2.camel@kazak.uk.xensource.com>
	<20140513105140.GI6332@zion.uk.xensource.com>
	<1399978530.21867.4.camel@kazak.uk.xensource.com>
	<20140513110359.GJ6332@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <20140513110359.GJ6332@zion.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Wei Liu <wei.liu2@citrix.com>
Cc: ian.jackson@eu.citrix.com, Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On Tue, May 13, 2014 at 12:03:59PM +0100, Wei Liu wrote:
> On Tue, May 13, 2014 at 11:55:30AM +0100, Ian Campbell wrote:
> [...]
> > > And presumably if we are to make this change we also need to update
> > > libxl.h to have LIBXL_JSON_GENERATE_NUMBER-ish? What would you suggest
> > > for the name?
> > 
> > Does this actually change the output syntax at all? If it is just a bug
> > fix then we don't need to announce it I think. Any consumers of the JSON
> > will have to cope with the buggy version (if they want to) irrespective
> > of any #define.
> > 
> 
> I will need to check. Presumably it generates a string or something.
> 
> We can treat it as a bug fix if we only use yajl_gen_number of uint64_t,
> other uint types are not affect.

>>From the JSON format perspective, every numbers are signed decimal, I
think (after a quick look on wikipedia). The parser may make a difference
between signed/unsigned decimal/interger.

For the default value, it might make sense to not include them, since
there are basicly not set values.

-- 
Anthony PERARD