Though we will no longer be comparing exactly against INT64_MAX, this is ok
because any value of that magnitude stored in a double will *also* have been
rounded up, so the comparison will work appropriately.

Fixed misalignment in JSON string due to space after \n being printed...

json_object_private: save 8 bytes in struct json_object in 64-bit arc…

json_object.c:set errno in json_object_get_double()

I also added a couple trivial, but related, suggestions.

closes #460

closes #422

- there is no need for _ref_count to be uint_fast32_t (the compiler
  might decide to use a 64-bit int). make it uint32_t instead.
- reorder the 32-bit integer fields (o_type and _ref_count) so that
  there is no wasted 4-byte gap after each of them.

Also try to accomodate formats to explicitly exclude the decimal (e.g. %.0f).

Because doing `json_tokener_parse(json_object_get_string(src))`
feels sloppy, dirty, and makes me want to cry at night
sometimes.

Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>

Found with autofuzz in GDAL

merge upstream

Add a comment mentioning the limitation even though the _ref_count value is hanled atomically.

This is EmielBruijntes' "Atomic updates for the refcount"

want to merge the original repository

2.replace json_object_get/put API with json_object_retain/release, as they operate the reference counter, and confused with array_list_get/put_idx.
3.replace array_list_get/put_idx API with array_list_get/insert to make them more clear to use.

Avoids undefined behavior.  Found by autofuzz.

If we want to override `strerror()` in libjson-c
to make tests consistent across platforms, we
need to do it build-wide as configure/build
option.

Apple linkers make it really hard to override functions
at link-time, and this seems to be locked down on travis-ci.org
[ for security reasons I assume ].
While I got it to work locally, it did not work
when running on travis.

Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>

Issue originally found in the json-c 0.11 internal copy in GDAL but also found
in latest git version.

If doing things like
json_object* obj = json_object_new_double(1e300);
json_object_set_serializer(obj, json_object_double_to_json_string, "%f", NULL);
json_object_to_json_string(obj)

    size = snprintf(buf, sizeof(buf),
        format ? format :
          (modf(jso->o.c_double, &dummy) == 0) ? "%.17g.0" : "%.17g",
          jso->o.c_double);
will return a value greater than 128 since at least 300 characters are needed.
This value is then passed to printbuf_memappend(pb, buf, size); that tries to
read size bytes in buf.

So we should clamp size to sizeof(buf). And on Windows, _snprintf() returns -1
in that situation, so deal also with this case.

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=1682
Credit to OSS-Fuzz