Tyler Erickson [Mon, 20 Oct 2025 18:10:57 +0000 (12:10 -0600)]
bug: Fixing runtime issue with test_util_file.c in Windows
Windows was failing tests due to how the Windows API works with some of the calls used.
When opening and reading a file O_BINARY is needed otherwise it fails for size checks. This is due to how Windows handles newlines and counts between text and binary mode file reads.
Also fixed is the test for /dev/null.
In Windows, this fails, but crashes due to a missing return statement when it cannot open this file.
I also tried telling windows to open the special file NUL, however that leads to a CRT crash later in the test that cannot be stopped and will always fail. Rather than fail a test that Windows will always fail, it has been disabled in that specific case.
Tyler Erickson [Mon, 20 Oct 2025 18:08:01 +0000 (12:08 -0600)]
make: Adding support for building json-c with meson
Adding meson build files for json-c that work similarly to the cmake build files.
Where it made sense, I reused existing cmake .h.in files or generated entirely from meson.
All tests were done with GCC and Clang in ubuntu 24.04, Windows using MSVC 2022 and Clang-cl from llvm's repo using version 21.1.3
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>
json_pointer: introduce json_pointer_get_internal() for internal usage
For JSON patch, we require that we get access to the parent of a JSON
object as well in order to do some operations via the API.
For example, given the object:
{
"foo": "bar",
"array", [ 1, 2, 3]
}
Using JSON pointer with the path
* '/foo' will return 'bar' of type string
* '/array/0' will return '1', of type integer
The problem is, that if we do 'json_object_put()' on any of the objects
above, this will not detach them from the parent, because there is no
information back to the parent.
One way to fix this, is to introduce links back to the parent, and have
these links be made by 'json_object_array_{put,insert}_idx()' and
'json_object_object_add{_ex}()'[1].
[1] For json_object_object_add_ex() we would need to de-constify the second
parameter, as we need to change it's internal state when being added to a
parent object. It may break some applications, but who knows.
But, since this information is needed mostly for JSON patch, another way to
address this, is to also retrieve the parent of an object via JSON pointer
and use json_object_object_del() and json_object_array_del_idx() on the
object's parent.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
projects / thirdparty / json-c.git / log
