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

[Jason Andryuk <jason.andryuk@xxxxxxx>]

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.

Regards,
Jason