Matthias Gatto [Thu, 2 Jun 2022 15:10:21 +0000 (17:10 +0200)]
add JSON_C_TO_STRING_COLOR option
This option enable color in json_object_to_json_string_ext.
I've try to made something similar to jq output,
but I've color true/false and null in purple,
as it's what is common color scheme used in programing language in emacs.
also add a '-c' option into json_parser to test it.
note: that I could have done a color() function similar to
what is done with indent(), but as the code is pretty small
I've keep it as it. so if you want me to use a subfunction
tell me and I'll do it.
Stop linking a copy of _json_c_strerror() (strerror_override.c) into the tests.
That hasn't been needed since since commit 6068d3f, which changed that code to
check an env var instead ("_JSON_C_STRERROR_ENABLE").
Fixes issue #812, about dup symbols in static builds with clang.
Bump up the minimum cmake version to 3.9.
This gets us up to a version that supports features we're already using
(i.e. add_compile_options), but stops short of a cmake that requires
c++11, which some OSes still don't support.
Closes issue #774
Apply same EINVAL handling to json_parse_uint64() as was done for json_parse_int64(). Document that overflow/underflow for these functions is not an error, but sets errno=ERANGE.
Even Rouault [Tue, 16 Aug 2022 09:11:55 +0000 (11:11 +0200)]
get_time_seed(): silence warning emitted by Coverity Scan static analyzer
It warns about the return of time() being truncated to 32 bit, which is
not an issue here.
(this warning was emitted because of the https://github.com/OSGeo/gdal
project embedding a copy of libjson-c and running Coverity Scan
analysis)
Khem Raj [Sun, 14 Aug 2022 07:46:28 +0000 (00:46 -0700)]
json_pointer.c: Move idx_val declaration to top of function
This helps compiling with MS compiler, error seems to be
due to defining a variable within the body of the function
its allowed in c99 but not in c89. This should fix build with
MSVC 16.0.40219.1 compiler from Visual Studio 14 2015
Khem Raj [Sun, 14 Aug 2022 03:37:03 +0000 (20:37 -0700)]
Fix build with clang-15+
Fixes
json_util.c:63:35: error: a function declaration without a prototype is deprecated in all versions of C [-We
rror,-Wstrict-prototypes]
const char *json_util_get_last_err()
^
void
When serializing with JSON_C_TO_STRING_PRETTY set, keep the opening and closing curly or square braces on same line for empty objects or arrays. Issue #778.
Fix memory leak with emtpy strings in json_object_set_string
When a json string object is updated with a bigger string, a new
malloc'ed buffer is used to store the new string and it's size is made
negative to indicate that an external buffer is in use.
When that same json string object get's updated again with an empty
stirng (size = 0), the new external malloc'ed buffer is still used.
But the fact that the new size value is not negative removes the
indicator that the externally malloc'ed buffer is used.
This becomes a problem when the object get's updated again with any
other string, because a new buffer will be malloced and linked to the
object while to old one won't be free'd.
This causes a memory leak when updating a json string with
json_object_set_stirng() which has previously been updated
with an empty string.
Specify dependent libraries, including -lbsd, in a more consistent way so linking against a static json-c works better. Related issue #766
Use target_link_libraries, plus fill in Libs.private in json-c.pc so pkg-config --static --libs works appropriately.
Also, only link against libbsd when arc4random is actually found there.
Include the tests and apps directories at the _end_, since order in the
cmake rules matters, and fix compile warnings now that we're building
those sources with all the regular flags.
If memory allocation fails in json_c_set_serialization_double_format or
json_object_copy_serializer_data then return with an error value and
preserve previous values without overriding them with NULL.
json_tokener_free(tok);
return 0;
}
```
- Compile and run poc, assuming you have enough free heap space:
```
gcc $(pkg-config --cflags --libs) -o poc poc.c
./poc
0x559421e15de0
{ "A": "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
```
- Reduce available heap and run again, which leads to truncation:
```
ulimit -d 10000
./poc
0x555a5b453de0
{ "A": "B" }
```
- Compile json-c with this change and run with reduced heap again:
```
ulimit -d 10000
./poc
(nil)
```
The output is limited to 70 characters, i.e. json-c parses the 8 MB
string correctly but the poc does not print all of them to the screen.
The truncation occurs because the parser tries to add all chars up
to the UTF-8 formatted 'B' at once. Since memory is limited to 10 MB
there is not enough for this operation. The parser does not fail but
continues normally.
Another possibility is to create a json file close to 2 GB and run a
program on a system with limited amount of RAM, i.e. around 3 GB. But
ulimit restrictions are much easier for proof of concepts.
Treat memory errors correctly and abort operations.
Most of these sites support HTTPS (some forward to HTTPS when accessing
the HTTP versions). Use HTTPS directly if supported.
Some URLs led to 404 error pages. Adjusted the links to point to
new locations.
I did not adjust the Microsoft HTML Help Workshop link because it seems
that this software is not available anymore. Instead of removing the
link entirely I kept it there in case it helps someone to find the
software on archived websites.
You can see that sprintbuf does not return an error but length is still
the same, i.e. the string "string too long" has not been appended.
I would like to add this as a unit test but it really depends on the
operating system if printbuf_memset() would fail if not enough memory is
available or not.
It is possible to have a printbuf with "gaps", i.e. areas within the
print buffer which have not been initialized by using printbuf_memset.
Always clear memory in such cases.
Example:
```
struct printbuf *pb = printbuf_new();
printbuf_memset(pb, 10, 'a', 2);
```
In this case pb->buf[0] is '\0' but pb->buf[1] up to pb->buf[9] are
not set. The length would be 12 due to successful printbuf_memset.
Systems without vasprintf fall back to implementation in header file
vasprintf_compat.h. This version could run into heap overflow issues
with very long arguments or formats provoking a lot of output.
The vsnprintf function returns a negative value if more than INT_MAX
characters would be written since its int return type could not
handle this (and %n couldn't handle it either).
Before testing for a possible error value the additional char for
\0 is already added. A -1 error code would not be detected.
Increment only after implicitly casting to an unsigned value to avoid
signed integer overflow if INT_MAX has been returned.
Use va_copy to duplicate the original ap argument for multiple uses
on non-WIN32 systems. At least with glibc the test suite would fail
because the arguments are not reset after leaving the vsnprintf call.
Removed support for apparently very old glibc versions which do not
comply with vsnprintf standard descriptions. It breaks support for
modern ones which are not forced to return -1 in case of error. The
standard specifies merely "a negative value".
How to reproduce:
- Use a system without vasprintf
- Alternatively remove -D_GNU_SOURCE from CMakeLists.txt
- Compile and run:
Kizuna-Meraki [Thu, 17 Feb 2022 20:27:01 +0000 (21:27 +0100)]
Close file on error path.
The file was only be closed when there was no error and
was being left open when there was an error. By moving
the close(fd) statement out of the if-clause, the file
can be close regardless if there is an error or not.
After the file is closed, it can be checked for errors.
Even Rouault [Sun, 16 Jan 2022 19:50:56 +0000 (20:50 +0100)]
json_object_copy_serializer_data(): add assertion
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):
projects / thirdparty / json-c.git / log
