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
Added #ifdef conditions for MinGW because this compiler doesn't define
gcc atomic builtins, so __sync_val_compare_and_swap was not found
neither any of any __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* definition
This fix includes some fixes for config.h.win32 that was generating
some compiling errors on MinGW64 and also fix CMakeLists.txt in order to
give better support to MinGW and MSYS2
Hawciz pointed out that the previous commit modifies the public
interface of printbuf. Per his suggestion, sprintbuf() was restored
and a new pair of macros was added that wraps printbuf_memappend().
Using a wrapper macro instead of modifying sprintbuf() also reduces
function call overhead, bringing total performance gains to
approximately 400%.
These include support for printf() style args for path.
Adds support for calling with 'json_pointer_getf(obj, &res, "/foo/%d/%s", 0, bar)'
style args.
Makes it easier for doing more dynamic stuff/magic, without
needing to use vasprintf() externally.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This reverts commit aaba8c1080.
This commit breaks builddir != srcdir build, but, more importantly, it
also adds a dependency on a header, "config.h", which is not installed
and it's supposed to be private — since it's generated at configuration
time and it's not meant to be used by projects compiling against a
library.
I got this on Mac OS X at least.
Not sure if it shows up in other envs
error:
```
strerror_override.c:53:13: error: incompatible redeclaration of library function 'strerror' [-Werror,-Wincompatible-library-redeclaration]
const char *strerror(int errno_in)
```
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>