Tyler Erickson [Mon, 20 Oct 2025 17:39:04 +0000 (11:39 -0600)]
bug: Fixing Cmake build when using clang-cl
Clang-cl will fail to build and produce warnings about redefining existing symbols, mostly for float.h and math.h compatibility.
To resolve this, this moves the clang-cl detection earlier in the CMakeLists.txt so that CLANG_CL can be checked properly where there is an existing MSVC workaround for these symbols.
This resolves the build using the latest clang-cl from the LLVM clang repo as well as clang-cl that can be installed with MSVC 2022.
Eric Hawicz [Wed, 9 Jul 2025 01:02:52 +0000 (21:02 -0400)]
Make json_parse a bit more useful by adding -u (validate UTF8) and -P (specify arbitrary tokener parse flags), and read from stdin if no filename is provided.
Eric Hawicz [Sat, 9 Nov 2024 03:20:40 +0000 (22:20 -0500)]
Fix issue #875: cast to unsigned char so bytes above 0x7f aren't interpreted as negative, which was causing the strict-mode control characters check to incorrectly trigger.
Issue #842 - fix one particular sign conversion warning.
There are many others that show up if we were to add -Wsign-conversions,
but this is the only one using a literal constant.
/home/thomas/autobuild/instance-2/output-1/build/json-c-0.17/json_pointer.c: In function 'json_pointer_result_get_recursive':
/home/thomas/autobuild/instance-2/output-1/build/json-c-0.17/json_pointer.c:193:25: error: 'idx' may be used uninitialized in this function [-Werror=maybe-uninitialized]
res->index_in_parent = idx;
^
Eric Hawicz [Sat, 23 Sep 2023 02:26:21 +0000 (22:26 -0400)]
Take 2 fixing the placement of json_tokener_error_memory in the enum. (json_tokener_error_size is an actual error, *not* a measure of the size of the enum!)
These policies were all introduced before CMake 3.9, so they will automatically
be initialized to the new behavior when requesting a minimum version of 3.9.
Eric Hawicz [Sat, 29 Jul 2023 02:12:51 +0000 (22:12 -0400)]
Fix json_patch_apply handling of removing the whole document (i.e. "path":"").
Enable all disabled tests, add a few more including some with null documents.
Eric Hawicz [Thu, 27 Jul 2023 02:01:04 +0000 (22:01 -0400)]
Adjust the behavior of the args passed to json_patch_apply to make it easier to do in place modifications, and add a struct json_patch_error to report more details on failures.
Some tests may not have an 'expected' or 'error' field. Those are ignored.
One test was disabled manually via "disabled_in_json_c", because it tries
an impossible test, i.e. to add 2 "op" fields in the same patch entry,
something which is impossible in a JSON object.
For the 'error' cases, right now we only test that an error happens.
Later, we can extend this to check the error codes.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
json_patch: add first implementation only with patch application
Initially I wanted to also do a function that generates the JSON patch from
two JSON documents, but even just applying the JSON patch was a bit of
work, especially when needing to satisfy all the test-cases.
This change defines all the operation in the RFC6902. The addition isn't
too big (for the json_patch_apply() function), as part of the heavy lifting
is also done by JSON pointer logic.
All the ops were tested with the test-cases defined at:
https://github.com/json-patch/json-patch-tests
RFC6902: https://tools.ietf.org/html/rfc6902
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
JSON patch is a bit more clear on how some array operations should be
handled. Unfortunately, handling them on a case-by-case is a bit tricky
because it's difficult to satisfy properly an 'add' operating with a 'move'
operation and the basic json_pointer_set().
With json_pointer_set{f}() we use json_object_array_put_idx() to insert a
value at a certain index.
With JSON patch:
* for the 'add' operation, we need to insert a value at a given index,
which means shifting existing values by one to the right
- also, we cannot allow values to be inserted/added outside the bounds of
the array
* a 'move' operation, is described as a 'remove' and then an 'add';
for arrays this complicates things, because when we want to a move a
value within the array, we have to remove it first (during which the size
of the array is reduced by one); when the size of the array is reduced by
one, we can't add it to the last position in the array (before the
remove)
The only sane method to handle this (after a few considerations) is to
provide a callback to the function that does the final put/insert into
the array. That way, we can do some final checks where these are needed to
handle each corner-case.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
json_pointer: move array out-of-bounds check outside of is_valid_index()
The out-of-bounds check is useful when trying to index/obtain a value from
an array.
However, when we set a value to a specific JSON pointer, we can allow
values that are outside the length of the current array.
The RFC6901 doc isn't clear on that aspect, and doing so is a bit more
in-line with how json_object_array_{put,insert}_idx() functions behave.
This changes the behavior of json_pointer_set{f}() because now a value can
be set anywhere in the array.
Also, added a test-case for this behavior change.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
projects / thirdparty / json-c.git / log
