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
