Search Results for: feed

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

This release adds the option for case-insensitive comparisons and removes userdata and custom-serialization functions. For more details, please refer to the changelog below.

Changelog:

0.99.7 2017-10-17
– added option for case-insensitive comparisons
This permits to search for json keys in a case-sensitive way. The default is “off”, as this is against the JSON spec. However, rsyslog needs this capability to increase usability inside the variable system.
We add a new API call to switch between case-sensitive and case-insensitive comparison, with case-sensitive being the default.
closes https://github.com/rsyslog/libfastjson/issues/142
– Removed userdata and custom-serialization functions
Reasoning (from pull request):
The library uses the concept of “userdata” and “custom serialization functions” that can be set from user space. However, to effectively make use of this feature, a user must have a deep understanding of the internal data representation of the library, which makes this feature not very useful.
But what is worse: internally, the library itself also sometimes assigns data to this userdata member (especially when working with doubles), and it also sometimes assigns alternative serialization functions. This makes the feature even more unusable, because as a user you never can know when the userdata pointer is save to use for your own settings, and when you must leave it alone because it is used by the library.
Long story short. In this pull request I got rid of the userdata pointer completely. The case where the library was using the “userdata” (for storing the original string representation of a parsed double) has been moved into the union that is already used for storing values.
see also: https://github.com/rsyslog/libfastjson/pull/141
Thanks to Emiel Bruijntjes for the patch.

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

This release fixes a build issue under Solaris.

Changelog:

0.99.6 2017-05-12
– fix a build issue under Solaris

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.