libfastjson 0.99.5 released

This is a new fork of the json-c library, which is optimized for liblognorm processing.

This release brings a lot of fixes and changes. Most notably, libfastjson now builds under AIX and under Solaris again.

Changelog:

0.99.5 2017-05-03
– fix tautology comparison in tautology in `fjson_object_iter_equal`
– made build under Solaris again
– made to build under AIX
Thanks to github user purnimam1 for the patch
– fix floating point representation when fractional part is missing
see also https://github.com/rsyslog/libfastjson/issues/126
Thanks to Jan Gerhards for the patch.
– m4: fix detection of atomics
In cross-compilation, it is impossible to run code at configure time to
detect the target specifics.
As such, AC_TRY_RUN fails miserably to detect reliably that atomic
intrisics are present in a toolchain, and decides they are not just
because this is cross-compilation.
Instead of AC_TRY_RUN, use AC_LINK_IFELSE that does not need to actually
run code, since all we’re interested in is whether the intrisics are
present (or not). Fix both the 32- and 64-bit variants, even if the
latter is not used currently.
Fixes build failures detected by the Buildroot autobuilders, like:
http://autobuild.buildroot.org/results/23a/23ac0e742ed3a70ae4d038f8c9eadc23e708f671/build-end.log
http://autobuild.buildroot.org/results/192/1923d0b570adba494f83747a9610ea6ec35f5223/build-end.log
and many other cases, espcially on architectures where such intrsics are
present, but where the toolchain does not have threads (and anyway, it
is much more efficient to use the intrisics rather than use mutexes).
Thanks to Yann E. MORIN for the patch.
– add fjson_object_dump() and fjson_object_write() functions
… that make it possible to dump the json tree without having to
dynamically allocate a string, and to write the tree to a FILE*.
NOTE: right now, most of the code is simply copied from the functions
that use the “printbuf” for writing the data. I have not touched the old
printbuf-implementation, because some other code may still rely on it.
However, in my opinion these printbuf-based functions (if it is desirable
to keep them in the first place) can now be re-implemented to use the more
flexible fjson_object_dump() function.
MAINTAINER NOTE: we need to performance-test any new implementation and will
do so. The results will ultimately decide which parts of the code remain in
the codebase.
Thanks to Emiel Bruijntjes for the patch.