Signed-off-by: Jakov Smolic <jakov.smolic@sartura.hr>

Fix "may be used uninitialized" Release build failure

Fixes https://github.com/json-c/json-c/issues/647

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

Cast to unsigned char instead of int when calling tolower (Fixes #645)

See also PR #639 and issue #621

build: Add a symbol version to all exported symbols

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>

In practice, the sizes of the signed and unsigned integer types will
almost cetainly be the same, but this is more correct.
Pointed out in issue #638.

This causes previously failing strings like "123-456" to return a valid json_object with the appropriate value.  If you care about the trailing content, call json_tokener_parse_ex() and check the parse end point with json_tokener_get_parse_end().

Deprecate the json_parse_double() function from json_util.h

Add an optional way to use an incremental chunk size ($TEST_PARSE_CHUNKSIZE)
for all of the single_basic_parse tests, in additional to the regular way.

While here, drop the utf8_replacement_char that is unnecesarily added if we run out of input in the middle of a unicode escape.  No other functional changes (yet).

fix issue 616: support the surrogate pair in split file.

Also add the json_object_new_array_ext, array_list_new2, and array_list_shrink functions.

Json object split

Issue #508: `-fPIC` to link libjson-c.a with libs

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