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>
The index cannot be negative when parsing in is_valid_index(), because we
don't allow the '-' character in a string before we get to the strtol()
function.
So, might as well remove the negative check (for idx) in is_valid_index()
and convert it to size_t. That may allow for higher values for the index
(which can be insane, but some people may want to try it).
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
tests: test1: add test cases for json_object_array_insert_idx()
This change adds a few test cases to test the behavior of the new
json_object_array_insert_idx() function, to make sure it behaves according
to specification in doc-string.
This test uses assert() vs the old method of comparing outputs.
This will cause the test to fail because the outputs won't match, since the
assert() will kick in.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
json_object: introduce json_object_array_insert_idx() API function
The behavior of the json_object_array_put_idx() is that, if a user wants to
insert an element inside a JSON array, the element will be replaced.
For some cases, a user would want to insert an element into the JSON array
and shift the elements to the right.
For indexes that are outside the length of the current array this behaves
like json_object_array_put_idx().
If a user wants to enforce that the JSON array is not expanded, then the
json_object_array_length() function can be used to guard against that.
The main driver for this change is JSON patch, where the 'add' operation in
an array means inserting a value at a certain index and shifting everything
by one.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
json_pointer: fix comments about printf() variants of set/get()
These were wrong. Some details about the json_pointer_setf() &
json_pointer_getf() were added in the json_pointer_set() &
json_pointer_get() doc-strings.
This change removes them.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
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.
projects / thirdparty / json-c.git / log
