Re: [PATCH V4 09/24] libxl_json: introduce parser functions for builtin types

[Wei Liu <wei.liu2@citrix.com>]

On Tue, May 13, 2014 at 12:28:42PM +0100, Anthony PERARD wrote:
> 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.
> 

Can you confirm that the existing consumer (QEMU?) will not care if those
values are absent in JSON object? If QEMU uses our parser then it should
be fine.

Wei.

> -- 
> Anthony PERARD