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 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.

And there's probably no tests for JSON_NUMBERs. So I guess first step
would be to write a test that have numbers that can't be converted to
`long long` and see what happens.

Thanks,

-- 
Anthony PERARD