3dad694 and 6dd8618 , the decs mast keep the same as the enum change the post

Resolve build issue in tokener_parse_ex_fuzzer.c

CMake: remove needless policy setting

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.

Let json-c be used with obsolete compilers

Added option to disable app build

json_patch: add first implementation only with patch application

Enable all disabled tests, add a few more including some with null documents.

Add comments describing when the fields of the internal struct json_pointer_get_result are valid.

Essentially, this change adds the test cases from this repo:
   https://github.com/json-patch/json-patch-tests

Specifically:
   https://github.com/json-patch/json-patch-tests/blob/master/spec_tests.json
   https://github.com/json-patch/json-patch-tests/blob/master/tests.json

The files were taken at the date of this commit, at git hash
  ea3af85790

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>

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>

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.

Signed-off-by: Matthias Gatto <matthias.gatto@protonmail.com>

json_tokener_parse_ex: handle out of memory errors

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.

docs: update to Internet Standard reference

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

Problem: cmake 3.25.1 warns about CMP0042 not being set

Problem: confusing error message in snprintf_compat.h