This makes Coverity Scan happier since it believes that the initial
check ``if (!src->_userdata && !src->_user_delete)`` could mean that
src->_user_data may be nullptr.
Current behaviour is perfectly valid, since wrap-over upon overflow is
well defined behaviour for unsigned types, but it is nevertheless nice to be
able to build with -fsanitize=undefined,unsigned-integer-overflow
There is no significant effect on the generated assembly as can be seen
on the diff of objdump -d output on a optimized build (the compiler
just decided to switch the order of a comparison):
@@ -135,8 +135,8 @@
1d0: 0f 84 70 ff ff ff je 146 <json_escape_str+0x146>
1d6: 4c 3b 24 24 cmp (%rsp),%r12
1da: 0f 85 2d ff ff ff jne 10d <json_escape_str+0x10d>
- 1e0: 49 39 f4 cmp %rsi,%r12
- 1e3: 0f 87 b7 00 00 00 ja 2a0 <json_escape_str+0x2a0>
+ 1e0: 4c 39 e6 cmp %r12,%rsi
+ 1e3: 0f 82 b7 00 00 00 jb 2a0 <json_escape_str+0x2a0>
1e9: 48 8b 44 24 18 mov 0x18(%rsp),%rax
1ee: 64 48 33 04 25 28 00 xor %fs:0x28,%rax
1f5: 00 00
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
Even Rouault