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>

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.

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

Solution: set it explictly to OLD behavior

The warning is as follows:

```
Compatibility with CMake < 2.8.12 will be removed from a future version of CMake.
```

Solution: set it at 2.8.12

Use target_link_libraries, plus fill in Libs.private in json-c.pc so pkg-config --static --libs works appropriately.
Also, only link against libbsd when arc4random is actually found there.

cmake rules matters, and fix compile warnings now that we're building
those sources with all the regular flags.

Mostly found with codespell and during code review.

Update the README to better explain this, and make a few other tweaks.

This change syncs the public header include install location with what gets written into pkgconfig file.

To avoid target exe file export JSON functions.

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>

Fixes the following warning:

json_pointer.c:230:7: warning: implicit declaration of function
    'vasprintf' is invalid in C99 [-Wimplicit-function-declaration]
            rc = vasprintf(&path_copy, path_fmt, args);

Lower overhead than opening & reading from /dev/urandom, and works
in chroots and other situtations where /dev/urandom is not available.
Falls back to existing methods when kernel doesn't support the syscall.

Example:
mkdir build && cd build
cmake -DOVERRIDE_GET_RANDOM_SEED='do { extern uint32_t getMsTicks(void); int ms = getMsTicks() * 433494437; return ms; } while(0)' ..

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>

Json object split

json-c has symbol collisions with other popular C JSON libraries.
To prevent random crashes in downstream applications that may use a
library which depends on json-c, the solution is to statically link
libjson-c.a into those libraries.

`-fPIC`/`-fPIE` is required when building a `.a` so it can be linked
into a `.so`.

The default is now that string data is stored inline at the end of json_object, though to allow for json_object_set_string() to set a _longer_ string, we still need to allow for the possibility of a separate char * pointer.
All json types have been split out now, next step it cleanup.

Using thread-local storage may not be desired in all environments
and/or use-cases, thus there should be an option to disable its use
on purpose.

Fixes #451.

This is intended to provide a way, during development, to test out the memory
and performance impacts of a change.