Fix use-after-free in json_tokener_new_ex()

The failure path taken in the event of printbuf_new() returning NULL
calls free() on tok->stack after already having freed tok. Swap the
order of the two calls to fix an obvious memory access violation.

Fixes: bcb6d7d347 ("Handle allocation failure in json_tokener_new_ex")
Signed-off-by: Juuso Alasuutari <juuso.alasuutari@gmail.com>

CMake create uninstall target if unix generator is used

Add AfterCaseLabel to .clang-format

This is to fix the behavior that might've changed between older versions of clang-format, I'm not sure.
Version 10 tries to put the bracket on the same line as case without this.

Check __STDC_VERSION__ is defined before checking its value

Prevent an undef warning regarding __STDC_VERSION__ by checking whether it is defined before checking its value.

To avoid target exe file export JSON functions.

[RFC] json_pointer: allow the feature to be disabled

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>

Fix unused variable for Win32 build in random_seed.c

fix invalid unsigned arithmetic.

random_seed: on error, continue to next method

fix compilation with clang

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

instead of exiting the process

Fixed test1 regression.

SIZEOF_SIZE_T might be only defined in config.h.

Include config.h for these systems to pass tests which are only
supposed to be run on 32 bit systems.

Fixes issue #666.

Handle more allocation failures in json_tokener* functions

Validate size arguments in arraylist functions.

The array_list_new2 function, which is externally reachable through
json_object_new_array_ext, does not check if specified initial size
actually fits into memory on 32 bit architectures.

It also allows negative values, which could lead to an overflow on these
architectures as well. I have added test cases for these situations.

While at it, also protect array_list_shrink against too large
empty_slots argument. No test added because it takes a huge length
value, therefore a lot of items within the array, to overflow the
calculation. In theory this affects 64 bit sytems as well, but since the
arraylist API is not supposed to be used by external applications
according to its header file, the call is protected due to int
limitation of json_object_array_shrink.

Limit strings at INT_MAX length

Properly format errnos in _json_c_strerror

Prevent signed overflow in get_time_seed

Casting time(2) return value to int and multiplying the result with
such a constant will definitely lead to a signed overflow by this day.

Since signed overflows are undefined behaviour in C, avoid this.

Casting to unsigned is more than enough since the upper bits of a
64 bit time_t value will be removed with the int conversion anyway.

The allocation of printbuf_new might fail. Return NULL to indicate tis
error to the caller. Otherwise later usage of the returned tokener would
lead to null pointer dereference.

Several issues occur if a string is longer than INT_MAX:

- The function json_object_get_string_len returns the length of a string
  as int. If the string is longer than INT_MAX, the result would be
  negative.
- That in turn would lead to possible out of boundary access when
  comparing these strings with memcmp and the returned length as done in
  json_object_equal.
- If json_escape_str is called with such strings, out of boundary
  accesses can occur due to internal int handling (also fixed).
- The string cannot be printed out due to printbuffer limits at
  INT_MAX (which is still true after this commit).

Such huge strings can only be inserted through API calls at this point
because input files are capped at INT_MAX anyway.

Due to huge amount of RAM needed to reproduce these issues I have not
added test cases.

The comment only aligns correctly if tab size is 4. Replaced
spaces with tabs to stay in sync with style of other lines.

The function _json_c_strerror does not properly format unknown errnos.
The int to ascii loop ignores the leading digit if the number can be
divided by 10 and if an errno has been formatted, shorter errnos would
not properly terminate the newly created string, showing the ending
numbers of the previous output.

A test case has been added to show these effects.

Since this function has been introduced for tests, the effect of this on
real life code is basically non-existing. First an environment variable
has to be set to activate this strerror code and second an unknown errno
would have to be encountered.

See also issue #658.

Use GRND_NONBLOCK with getrandom.

The json-c library is used in cryptsetup for LUKS2 header information.
Since cryptsetup can be called very early during boot, the developers
avoid getrandom() calls in their own code base for now. [1]

Introducing a blocking getrandom() call in json-c therefore introduces
this issue for cryptsetup as well. Even though cryptsetup issues do not
have to be json-c issues, here is my proposal:

Let's use a non-blocking call, falling back to other sources if the call
would block. Since getrandom() accesses urandom, it must mean that we
are in an early boot phase -- otherwise the call would not block
according to its manual page.

As stated in manual page of random(4), accessing /dev/urandom won't
block but return weak random numbers, therefore this fallback would work
for json-c.

While at it, fixed the debug message.

[1] https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/47
    which references to https://lwn.net/Articles/800509/

Fixed warnings