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>
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>
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>
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>
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>
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>
Some users may not want to included it in their build/system. So allow a
cmake symbol to disable it.
A user can do 'cmake -DDISABLE_JSON_POINTER=ON <json_c_root_dir>' and
disable the json_pointer functionality. That saves about 17 KB (on an
x86_64) machine. This may be useful on smaller embedded systems; even
though the saving would be fewer kilobytes.
One thing that also needs to change a bit, is that the 'json.h' be
autogenerated via cmake, in order to conditionally include that
"json_pointer.h" file.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The intent is to be able to disable some features that get built into the
library. When we do that, we also need to disable some tests.
It's easier when adjusting a variable that contains the list of test names,
versus modifying the list in the foreach() statement.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems to perform better than outputting to string
and re-parsing it.
BENCHMARK - 1000000 iterations of 'dst2 = json_tokener_parse(json_object_get_string(src2))' took 20 seconds
BENCHMARK - 1000000 iterations of 'dst2 = json_tokener_parse(json_object_get_string(src2))' took 7 seconds
It should make a difference on embedded systems.
The test was performed on a i5 desktop CPU [~3.5 years of age].
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Because doing `json_tokener_parse(json_object_get_string(src))`
feels sloppy, dirty, and makes me want to cry at night
sometimes.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Always include <string.h> before _json_c_strerror() definition.
Should fix linker issues on MSVC.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
If we want to override `strerror()` in libjson-c
to make tests consistent across platforms, we
need to do it build-wide as configure/build
option.
Apple linkers make it really hard to override functions
at link-time, and this seems to be locked down on travis-ci.org
[ for security reasons I assume ].
While I got it to work locally, it did not work
when running on travis.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
On Apple this seems to fail the `test_locale` test,
which would imply that the `uselocale` function
does not behave as expected.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
ugh... seems cppcheck is not packaged for OS X
And `set -e` exposes this.
And also `cppcheck` seems to exit with non-zero
exit codes by default [even if errs found].
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems that test1 is failing, but travis is not catching it.
Likely, this is because the `cppcheck` returns success
and we need to bail on the `make check` step.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
These include support for printf() style args for path.
Adds support for calling with 'json_pointer_getf(obj, &res, "/foo/%d/%s", 0, bar)'
style args.
Makes it easier for doing more dynamic stuff/magic, without
needing to use vasprintf() externally.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
I got this on Mac OS X at least.
Not sure if it shows up in other envs
error:
```
strerror_override.c:53:13: error: incompatible redeclaration of library function 'strerror' [-Werror,-Wincompatible-library-redeclaration]
const char *strerror(int errno_in)
```
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Alexandru Ardelean