Re: [XEN PATCH 06/11] libxl: convert libxl__json_object_to_yajl_gen to libxl__json_object_to_libjsonc_object

[Anthony PERARD <anthony@xxxxxxxxxxxxxx>]

On Sun, Aug 31, 2025 at 10:51:53AM -0400, Jason Andryuk wrote:
> On 2025-08-29 09:56, Anthony PERARD wrote:
> > On Wed, Aug 27, 2025 at 11:37:07AM -0400, Jason Andryuk wrote:
> > > On 2025-08-08 10:55, Anthony PERARD wrote:
> > > > +    case JSON_NUMBER:
> > > > +        *jso_out = json_object_new_string(obj->u.string);
> > > 
> > > Is JSON_NUMBER calling json_object_new_string() correct?  It looks like 
> > > the
> > > yajl code falls back to a string, so that is okay but surprising.
> > 
> > Yeah, I think that's correct.
> > :-( maybe not. Even if we have these too comments:
> > 
> >      In libxl_internal.h, enum libxl__json_node_type:
> >          /* number is store in string, it's too big to be a long long or a 
> > double */
> >          JSON_NUMBER  = (1 << 4),
> > 
> >      In json_callback_number():
> >          /* If the conversion fail, we just store the original string. */
> > 
> > With yajl, we call yajl_gen_number(), which probably write 2^128 as:
> > 
> >      340282366920938463463374607431768211456
> > 
> > but this new json-c generator would write instead:
> > 
> >      "340282366920938463463374607431768211456"
> > 
> > I guess we might be able to replicate the same behavior by using
> > json_object_set_serializer() or json_object_new_double_s() (which use
> > the former). But I don't know if it is worth the effort. I hope we won't
> > have int bigger than 64 bits.
> 
> I didn't check, but I thought uint64_t is the biggest size libxl uses.

Yes, but we also parse json that are produce else where. (could be file
saved by libxl, but also json produced by QEMU)

Anywhy, I investitaged this a bit, and it's very unlikely that a
`JSON_NUMBER` would be created, so it's even less likely that this
`case` would happen. But I've change the call to
`json_object_new_string` by:

    /*
     * Use json_object_new_double_s() to rewrite the number exactly as
     * we parsed it. When generating the JSON string the value `0` will
     * be ignored and `obj->u.string` will be written instead.
     */
    *jso_out = json_object_new_double_s(0, obj->u.string);

That way, we get the same json blob, with both library.

Cheers,

-- 
Anthony PERARD