64-bit integer support?

[bmah888]

On the iperf3 project (https://github.com/esnet/iperf), we use a version of cJSON that's been modified to support 64-bit integers. It introduces a dependency on stdint.h but is otherwise fairly straightforward. Is there any interest in supporting this functionality in the main cJSON sources? Thanks!

[FSMaxB]

cJSON won't support 64 bit numbers. One reason is that C89 doesn't provide a 64 bit integer type. The other reason is simplicity. The 53 bits from a double are enough for most purposes.

See also #151, #87, #14

[hbhdwxf]

er....I also met this problem.

[TobiasUhmannVoss]

Besides living with the inaccuracy of big numbers greater 2^53 or dividing the 64bit number into two 32-bit numbers, there is also the possibility to add raw values, e.g.:

int64_t big_number;

char decimal[64 + 1];
snprintf(decimal, sizeof(decimal), "%" PRId64, big_number);

cJSON *json = cJSON_CreateRaw(decimal);
assert(json != NULL);

[bmah888]

For the record we're still using a patched cjson.[ch] in iperf3 in the year 2024 (8 years later) because we really do need and use a 64-bit integer type for our measurements and statistics. It's too bad the core cJSON project doesn't want to implement this feature, but that's totally the project maintainers' decision (and I don't implement all the enhancement requests people send into iperf3 either). In any case we're grateful to everyone involved with cJSON for making it available to the community.

[sbvoxel]

@bmah888 Just in case you didn't know, it seems to me like your implementation supports 53 bits, but not 64-bit integers. It's not enough to replace their 32-bit int logic with 64-bit logic because lots of places push everything through a double, causing very large integers to lose precision in the lower bits.

For instance, parsing makes use of 'strtod' but you'll want integer parsing when no decimal point is seen, so that you can directly get a 64-bit integer instead of retrieving it from a double, which will lose precision for integers larger than 53-bits.

Same when the number is being set, it must not go through a double.

The whole implementation is a bit of a brain teaser anyway with the way they handle ints and doubles, and how they compare them to figure out whether the value is a decimal or not. I'm simply replacing this with a union where I tag whether the number is a double or int. Much simpler.