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>

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 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>

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.

See also PR #639 and issue #621

With this version script, newly-linked binaries that depend on the
json-c shared library will refer to its symbols in a versioned form,
preventing their references from being resolved to a symbol of the same
name exported by json-glib or libjansson if those libraries appear in
dependency search order before json-c, which will usually result in
a crash. This is necessary because ELF symbol resolution normally uses
a single flat namespace, not a tree like Windows symbol resolution.
At least one symbol (json_object_iter_next()) is exported by all three
JSON libraries.

Linking with -Bsymbolic is not enough to have this effect in all cases,
because -Bsymbolic only affects symbol lookup within a shared object,
for example when json_object_set_serializer() calls
json_object_set_userdata(). It does not affect calls from external
code into json-c, unless json-c was statically linked into the
external caller.

This change will also not prevent code that depends on json-glib or
libjansson from finding json-c's symbols and crashing; to prevent
that, a corresponding change in json-glib or libjansson would be needed.

Adding a symbol-version is a backwards-compatible change, but once
added, removing or changing the symbol-version on a symbol would be an
incompatible change that requires a SONAME bump.

Resolves: https://github.com/json-c/json-c/issues/621
(when combined with an equivalent change to libjansson).

Signed-off-by: Simon McVittie <smcv@collabora.com>