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.
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.
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.
Though we will no longer be comparing exactly against INT64_MAX, this is ok
because any value of that magnitude stored in a double will *also* have been
rounded up, so the comparison will work appropriately.
- there is no need for _ref_count to be uint_fast32_t (the compiler
might decide to use a 64-bit int). make it uint32_t instead.
- reorder the 32-bit integer fields (o_type and _ref_count) so that
there is no wasted 4-byte gap after each of them.
