The --default-symver linker option attaches a default version definition (the SONAME) to every exported symbol. It is supported since at least GNU binutils 2.22 in 2011 (older versions not tested).

With this version definition, newly-linked binaries that depend on the jansson shared library will refer to its symbols in a versioned form, preventing their references from being resolved to a symbol of the same name exported by json-c or json-glib if those libraries appear in dependency search order before jansson, which will usually result in a crash. This is necessary because ELF symbol resolution normally uses a single flat namespace, not a tree like Windows symbol resolution. At least one symbol (json_object_iter_next()) is exported by all three JSON libraries.

Linking with -Bsymbolic is not enough to have this effect in all cases, because -Bsymbolic only affects symbol lookup within a shared object, for example when parse_json() calls json_decref(). It does not affect calls from external code into jansson, unless jansson was statically linked into the external caller.

This change will also not prevent code that depends on json-c or json-glib from finding jansson's symbols and crashing; to prevent that, a corresponding change in json-c or json-glib would be needed.

Adding a symbol-version is a backwards-compatible change, but once added, removing or changing the symbol-version would be an incompatible change that requires a SONAME bump.

Resolves: https://github.com/akheron/jansson/issues/523 (when combined with an equivalent change to json-c).

I am not a jansson expert, please review and test carefully.

Can someone give me an example of ORing flags together? I'm trying to use JSON_INDENT and JSON_REAL_PRECISION, but I don't have a clue what it meant by ORing something. Thanks ahead of time.

Hi! I've been adding oss-fuzz support to some open-source projects (lz4, curl) and thought that I'd offer a fix for issue #479 raised by @Google-Autofuzz.

This takes the sample code they offered and puts it into your build tree. To actually get it into oss-fuzz you'll need to submit a patch in the oss-fuzz project; if this is something you're interested in I have a code branch ready to submit (just needs a contact email address for any bugs that it finds).

re: the raw Make commands: Annoyingly they've recently changed the behaviour of the LIB_FUZZING_ENGINE variable (it used to be a file, now its value is "-fsanitizer=fuzzer" (so now is a flag). The Make commands here mean that you can build a testcase loader without having to have that set up.

I also have a branch for adding cmake to version 2.3, if you are interested.

I don't expect you to pull this into your master, but it would be nice if you pulled it into a branch and give it a try. It detects a few extra things properly that your automake system doesn't (yet).

It should allow you to build with cmake, or build with autotools, with the same tree. Its not a disruptive change, and I prefer using cmake to using the supplied MSVC project files (I've been down that path before with other projects, its annoying).

cheers :)

I am building using c99 on HPE NonStop ia64 and x86. Test suite is failing as follows. Let me know what more information I can supply for diagnosis. Also, the -shared option is wrong on this platform. We need -Wshared and some LDFLAGS for export options.

=======================================
   jansson 2.14: test/test-suite.log
=======================================

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: run-suites
================

Suite: api
F..................
=================================================================
api/check-exports
=================================================================
--- logs/api/check-exports/exports      2022-03-19 18:10:13 -0500
+++ logs/api/check-exports/output       2022-03-19 18:10:13 -0500
@@ -1,81 +0,0 @@
-jansson_version_cmp
-jansson_version_str
-json_array
-json_array_append_new
-json_array_clear
-json_array_extend
-json_array_get
-json_array_insert_new
-json_array_remove
-json_array_set_new
-json_array_size
-json_copy
-json_deep_copy
-json_delete
-json_dump_callback
-json_dump_file
-json_dumpb
-json_dumpf
-json_dumpfd
-json_dumps
-json_equal
-json_false
-json_get_alloc_funcs
-json_integer
-json_integer_set
-json_integer_value
-json_load_callback
-json_load_file
-json_loadb
-json_loadf
-json_loadfd
-json_loads
-json_null
-json_number_value
-json_object
-json_object_clear
-json_object_del
-json_object_deln
-json_object_get
-json_object_getn
-json_object_iter
-json_object_iter_at
-json_object_iter_key
-json_object_iter_key_len
-json_object_iter_next
-json_object_iter_set_new
-json_object_iter_value
-json_object_key_to_iter
-json_object_seed
-json_object_set_new
-json_object_set_new_nocheck
-json_object_setn_new
-json_object_setn_new_nocheck
-json_object_size
-json_object_update
-json_object_update_existing
-json_object_update_missing
-json_object_update_recursive
-json_pack
-json_pack_ex
-json_real
-json_real_set
-json_real_value
-json_set_alloc_funcs
-json_sprintf
-json_string
-json_string_length
-json_string_nocheck
-json_string_set
-json_string_set_nocheck
-json_string_setn
-json_string_setn_nocheck
-json_string_value
-json_stringn
-json_stringn_nocheck
-json_true
-json_unpack
-json_unpack_ex
-json_vpack_ex
-json_vsprintf
-json_vunpack_ex

=================================================================
Suite: encoding-flags
............
Suite: invalid
..................................................
Suite: invalid-unicode
..................
Suite: valid
..................................
1 of 5 test suites failed
FAIL run-suites (exit status: 1)

Support merging values nested within objects. For instance, merging:

    {
	"foo": 1,
	"bar": {
	    "baz": 2
	}
    }

with

    {
	"bar": {
	    "baz": 3
	}
    }

results in

    {
	"foo": 1,
	"bar": {
	    "baz": 3
	}
    }

instead of overwriting the value for the bar key.

The jansson command is a utility for building and parsing JSON objects from the CLI. It is a simple stack machine on which operations can be performed. This command exposes the most important Jansson APIs.

Some embedded operation system only provide direct interface for file I/O, i.e. not supporting the native fopen()/fread() API. So I have to create a json_load_callback() wrapping to allow flexible input.

As we've already have a json_dump_callback(), it might be interesting for jansson to have one for loading too.

Update: tab space mixture fixed

This macro is used to conditionally generate GCC/CLANG attribute declarations if supported.

This allows the compiler to produce warnings on certain incorrect usages. json_sprintf and json_vsprintf will produce warnings on invalid format string. Many functions will produce a warning if the result is unused. Specifically functions which allocate new objects will warn if the result is ignored as this always results in a memory leak.

My application requires that objects preserve the order of elements when parsed. This modifies the hashtable code to also maintain a linked list of struct hashtable_pair pointers, in the order they are added to the hashtable. Iterator operations now use this instead.

It adds a bit more space to hashtables and key/value pairs, and adds a list append/remove operation on putting a new value, or deleting a value.

It does not modify the order on update: it preserves creation order, not update order.

I kind of butchered linked list handling. I couldn't break out of the "NULL terminates the list" mode of thinking, at least for append-only lists.

Hi,

I encountered an OOB read memory corruption bug when fuzzing Jansson.

Below you can find the crash log:

# ./prog -detect_leaks=0
INFO: Seed: 665849601
INFO: Loaded 1 modules   (10 inline 8-bit counters): 10 [0x5a3f90, 0x5a3f9a),
INFO: Loaded 1 PC tables (10 PCs): 10 [0x568020,0x5680c0),
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
INFO: A corpus is not provided, starting from an empty corpus
#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 27Mb
#19711  NEW    cov: 6 ft: 7 corp: 2/4b lim: 198 exec/s: 0 rss: 47Mb L: 3/3 MS: 4 InsertByte-InsertByte-ShuffleBytes-ShuffleBytes-
#19777  REDUCE cov: 6 ft: 7 corp: 2/3b lim: 198 exec/s: 0 rss: 47Mb L: 2/2 MS: 1 EraseBytes-
#524288 pulse  cov: 6 ft: 7 corp: 2/3b lim: 4096 exec/s: 262144 rss: 610Mb
#1048576        pulse  cov: 6 ft: 7 corp: 2/3b lim: 4096 exec/s: 262144 rss: 658Mb
#2097152        pulse  cov: 6 ft: 7 corp: 2/3b lim: 4096 exec/s: 262144 rss: 659Mb
#4194304        pulse  cov: 6 ft: 7 corp: 2/3b lim: 4096 exec/s: 262144 rss: 659Mb
#8388608        pulse  cov: 6 ft: 7 corp: 2/3b lim: 4096 exec/s: 262144 rss: 659Mb
#16777216       pulse  cov: 6 ft: 7 corp: 2/3b lim: 4096 exec/s: 254200 rss: 659Mb
#33554432       pulse  cov: 6 ft: 7 corp: 2/3b lim: 4096 exec/s: 252288 rss: 659Mb
#67108864       pulse  cov: 6 ft: 7 corp: 2/3b lim: 4096 exec/s: 246723 rss: 659Mb
#134217728      pulse  cov: 6 ft: 7 corp: 2/3b lim: 4096 exec/s: 241833 rss: 659Mb
AddressSanitizer:DEADLYSIGNAL
=================================================================
==1898031==ERROR: AddressSanitizer: SEGV on unknown address 0x610000050000 (pc 0x7f229f4f020b bp 0x7ffcf5010a30 sp 0x7ffcf5010938 T0)
==1898031==The signal is caused by a READ memory access.
    #0 0x7f229f4f020b in string_get /root/jansson-2.13/src/load.c:893:7
    #1 0x7f229f4f06f3 in stream_get.part.0 /root/jansson-2.13/src/load.c:158:13
    #2 0x7f229f4f0837 in stream_get /root/jansson-2.13/src/load.c:154:8
    #3 0x7f229f4f0837 in lex_get_save /root/jansson-2.13/src/load.c:233:13
    #4 0x7f229f4f0a32 in lex_scan /root/jansson-2.13/src/load.c:604:17
    #5 0x7f229f4f15da in parse_json.constprop.0 /root/jansson-2.13/src/load.c:868:9
    #6 0x7f229f4f1721 in json_loads /root/jansson-2.13/src/load.c:920:14
    #7 0x54dad3 in LLVMFuzzerTestOneInput /root/fuzzing/jansson/fuzz.c:12:9
    #8 0x4586a1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/root/fuzzing/jansson/prog+0x4586a1)
    #9 0x457de5 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) (/root/fuzzing/jansson/prog+0x457de5)
    #10 0x45a087 in fuzzer::Fuzzer::MutateAndTestOne() (/root/fuzzing/jansson/prog+0x45a087)
    #11 0x45ad85 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/root/fuzzing/jansson/prog+0x45ad85)
    #12 0x44973e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/root/fuzzing/jansson/prog+0x44973e)
    #13 0x472582 in main (/root/fuzzing/jansson/prog+0x472582)                                                                                                                                                  #14 0x7f229f1810b2 in __libc_start_main /build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16
    #15 0x41e4dd in _start (/root/fuzzing/jansson/prog+0x41e4dd)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /root/jansson-2.13/src/load.c:893:7 in string_get
==1898031==ABORTING
MS: 2 InsertRepeatedBytes-CopyPart-; base unit: 97d170e1550eee4afc0af065b78cda302a97674c
0x5b,0x5d,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67
,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x6
7,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x
67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0
x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,0x67,
[]gggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg
artifact_prefix='./'; Test unit written to ./crash-76b9ab07b593b8511d24aea00b925d60735e9d6c
Base64: W11nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dn
Z2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dn

The fuzzer I used was:

#include <jansson.h>
#include <stdio.h>

int LLVMFuzzerTestOneInput(const char *Data, size_t Size) {
        FILE *devNull;

        devNull = fopen("/dev/null", "w");

        json_t *root;
        json_error_t error;

        root = json_loads(Data, 0, &error);

        json_dumpf(root, devNull, 0);
        json_decref(root);

        fclose(devNull);

        return 0;
}

Kind Regards,

Jordy Zomer

I have noticed that the json_object_foreach(obj, key, value) function could not detect sub-objects if the sub-objects were at the middle of the objects. For example:

{
	"deviceIdentifier": "1B35D979",
	"payload": {
		"name": "startScan",
		"continuous": true,
		"reportNewTagsOnly": false,
		"powerLevel": 5,
		"interval": 6,
		"duration": 10
	},
	"timestamp": "2022-10-19T11:23:31Z"
}

The function failed to parse the "payload" sub-objects.

Any advice is appreciated
Thanks

platform: ubuntu 20.04 jansson-2.14 config: ./configure --build=x86_64-linux --host=arm-poky-linux-gnueabi --target=arm-poky-linux-gnueabi CFLAGS="-march=armv7ve -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a7"

error log:

make  check-TESTS
make[3]: Entering directory '/home/liushasha/Downloads/jansson-2.14/test'
make[4]: Entering directory '/home/liushasha/Downloads/jansson-2.14/test'
FAIL: run-suites
============================================================================
Testsuite summary for jansson 2.14
============================================================================
# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See test/test-suite.log
Please report to https://github.com/akheron/jansson/issues
============================================================================
make[4]: *** [Makefile:678: test-suite.log] Error 1
make[4]: Leaving directory '/home/liushasha/Downloads/jansson-2.14/test'
make[3]: *** [Makefile:786: check-TESTS] Error 2
make[3]: Leaving directory '/home/liushasha/Downloads/jansson-2.14/test'
make[2]: *** [Makefile:883: check-am] Error 2
make[2]: Leaving directory '/home/liushasha/Downloads/jansson-2.14/test'
make[1]: *** [Makefile:570: check-recursive] Error 1
make[1]: Leaving directory '/home/liushasha/Downloads/jansson-2.14/test'
make: *** [Makefile:642: check-recursive] Error 1

modified type of JANSSON_INSTALL_LIB_DIR/JANSSON_INSTALL_BIN_DIR/JANSSON_INSTALL_INCLUDE_DIR to string

if they were path, there will be a awkward situation: I expect to set the setting of .pc to (for Fedora rpm package) :

prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib64
includedir=${prefix}/include

Name: Jansson
Description: Library for encoding, decoding and manipulating JSON data
Version: 2.13.1
Libs: -L${libdir} -ljansson
Cflags: -I${includedir}

but we cannot set JANSSON_INSTALL_LIB_DIR to "lib64" because its type is path, so I will get like "${exec_prefix}//builddir/build/SOURCES/jansson-2.13.1/build/lib64"

does anybody has experience to add jannson toolkit into xilinx petalinux rootfs, espcial like add CONFIG_jannson instructions into user-roofsconfig then auto including it into petalinux rootfs ?

3ks

Hi everybody! sorry if this is not the right place, I actually cannot find a better place... I'll try to make it quick. I have been using libjansson for quite a while now (I think we are close to 10 years or so... - great library by the way) but just today I found myself in the need of a feature that I think is missing from the library.

It would be great if one could perform a quick search on a json document to verify if a certain key is present. In my use case, an application requires an information that might be present in a json document that can be requested to a web API (just an http request to a specific address). The document is very large, and the position of that particular key is not exactly known in advance. We could collect a few samples of this document to parse it exactly and dig into the hierarchy until we find it, but the server providing this information is not under our control and may change in the future, sending a slightly different json. That would require us to change the code that parses the received json.

What I was asking is an API that might look like this: jsont_t* json_find(json_t *document, const char *key); that returns NULL if key is not found inside the document or a json_t object in case it founds the key. What happens if there are many instances of that key has to be defined... the API could return an array of json_t* or the function could work as strtok() (that requires multiple calls to advance in the search from the last positive result).

What do you think? Any chances to see this function implemented in future releases?

Thanks for reading! Bye