I moved this before when I was using ssize_t in linkhash.c, but I moved
`struct lh_string` to `struct json_key` in a different file, so this isn't needed anymore

`struct lh_string` really needs to be renamed and moved to json_object.h

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.

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

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().

Also add the json_object_new_array_ext, array_list_new2, and array_list_shrink functions.

Remove all of the temporary defines, structures, old compat fuctions, extra fields, etc... that were needed during the conversion to a split set of json_object_* structures.

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.

Clean up the code in json_object_new_* a bit by dropping unnecesary json_object_base variables.

The current changes split out _only_ json_type_object, and thus have a number of hacks
 to allow the code to continue to build and work.

Originally  mentioned in issue #535.
When complete, this will probably invalidate #552.
This is likely to cause notable conflicts in any other significant un-merged
changes, such as PR#620.

A custom double formatter can lead to truncation of the rest of the
JSON document.

If a custom formatter completely fills the buffer used by snprintf
with a trailing dot or comma and the formatting option
JSON_C_TO_STRING_NOZERO has been specified, then an iterator moves
past the ending '\0' (off-by-one buffer overflow) to set an
additional '\0' and adds the first '\0' into the printbuf.

Since '\0' will eventually be considered the terminating character
of the complete printbuf result, all trailing characters are lost.

This leads to an incomplete JSON string as can be seen with the
test case.

The off-by-one can be noticed if compiled with address sanitizer.

Since this is a very special case and a malformed formatter could
do way more harm and is the responsibility of the user of this
library, this is just a protective measure to keep json-c code as
robust as possible.

Fix compiler errors and warnings when building on IBM operating systems such as AIX and IBM i.

Although it is currently working, it's worth to stick with the stdlib definition to avoid further problems

This is a recent regression since commit
6359b79847 which added various assert(0)
calls (often replacing return-s).
With Ming-W64 compiler, json-c build was failing with various errors of
the sort:

> /home/jehan/dev/src/json-c/json_object.c: In function 'json_object_int_inc':
> /home/jehan/dev/src/json-c/json_object.c:841:1: error: control reaches end of non-void function [-Werror=return-type]
>   841 | }
>       | ^
> In file included from /home/jehan/dev/src/json-c/json_object.c:17:
> /home/jehan/dev/src/json-c/json_object.c: In function 'json_object_get_double':
> /home/jehan/.local/share/crossroad/roads/w64/json-c/include/assert.h:76:4: error: this statement may fall through [-Werror=implicit-fallthrough=]
>    76 |   (_assert(#_Expression,__FILE__,__LINE__),0))
>       |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /home/jehan/dev/src/json-c/json_object.c:1070:7: note: in expansion of macro 'assert'
>  1070 |       assert(0);
>       |       ^~~~~~
> /home/jehan/dev/src/json-c/json_object.c:1072:3: note: here
>  1072 |   case json_type_boolean:
>       |   ^~~~

The problem is that Mingw-w64 does not consider assert() as a noreturn
(even assert(0)), because it has to be compatible by Microsoft
libraries. See the discussion here:
https://sourceforge.net/p/mingw-w64/bugs/306/

Instead let's create a new json_abort() function which is basically just
an abort() function with an optional message, for such cases where
abortion was non-conditional (using assert() and using the assertion
condition as a message here was clearly a misuse of the function). And
mark json_abort() as 'noreturn', as well as 'cold' for optimization
purpose (this is code we expect to never run, unless there is a bug,
that is).

Finally let's use this json_abort() instead of previous misused assert()
calls.