One of the great advantages of using json-c is to have very little code to write. Now with this json_object_object_get deprecation, we have to change:

int timeout = json_object_get_int(json_object_object_get(request, "timeout"));

to this:

int timeout;
{
    json_object * jTimeout;
    if ( json_object_object_get_ex(request, "timeout", & jTimeout) ) {
        timeout = json_object_get_int(jTimeout);
    } else {
        timeout = 0
    }
}

same thing for strings. We cannot do:

const char * name = json_object_get_string( json_object_object_get(request, "name"));

Sure, it relies on the fact that the API is nice enough to accept NULL object to the json_object_get_int and json_object_get_string functions.

And sure we can make our own wrapper:

json_object * json_object_object_get_old(json_object * obj, const char * name) {
    json_object * sub;
    return json_object_object_get_ex(obj, name, & sub) ? sub : NULL;
}

But I don't understand why you decided to remove something in the API that forces us to write more code.

Hello,

using platform : Renesas Synergy S5D9 ( some Cortex M4)

I have succesfully integrated the framework and it is working absolutely just how it is supposed to when the device is running with the external debugger. But when I run the firmware in "release mode" ( no debugger/ same configuration) the devices crashes somewhere after calling lh_get_hash. No watchdogs are being used, same configuration and everything for both use cases. Is there anything known about running the framework on embedded devices ? Some type of semi_hosting that doesn't exist when the device runs without debugger ? Does any workaround exist ? ( skipping the lh for example?)

I don't really know what to look for if I had to debug the programm myself, I don't even have a proper way to debug it, since the only way I can follow some paths is by turning led's on and off :( .

Any advice will be greatfully apreciated !

Best regards

I installed json-c with brew install json-c and it created the shims:

ls -l
...
libjson.0.dylib
libjson.dylib -> libjson.0.dylib
...

However in the autoconf tool when it does:

...
AC_CHECK_LIB([json], [json_object_get], [HAVE_JSON=yes], [], [])
...

it fails to find the function json_object_get in the libjson library.

Describe the bug In the application, we are using a shared library which is using json-c for its internal purpose. Later our application required to use a third party library, but its internally used jansson inside it for its functionality. Unfortunately when we run the application , it leads to memory corruption and process crashed.

Both of these libraries have multiple APIs with same name but different signature. Due to this, there is a memory corruption that resulted in crash.

The following APIs are available in both json-c and jansson libraries with the same name: json_object_get
json_object_iter_next

Steps To Reproduce This issue can easily reproduce with the following way:

• Application linked to libjson_c_lib.so and libjansson_c_lib.so. Both of these are wrapper libraries are using json-c and jannson internally.

• libjson_c_so wrapper library linked to libjson-c.so

• libjansson_c.so wrapper library linked to libjansson.so.

Tried statically linked one of the library but its not helped here. If we statically link jansson to wrapper library, json-c calls failed especially json_tokener_parse(). If we statically link json-c library, its resulted in same memory corruption.

This is probably related to #336

I link my cross-platform program (Linux/Mac/Windows) with json-c.

Today I updated and rebuilt json-c from master. Mac and Linux builds are ok, on Windows I get the following error:

error LNK2019: unresolved external symbol __json_c_strerror referenced in function __json_object_to_fd

The json-c library itself has been built successfully, but my program that links with it fails to be built now.

Using MSVC 14 (2015), 32-bit build, both Debug and Release fail.

I rolled back to this commit: c0b7d762b28d3ddc4dbaa4e8a27ba7c33d54d2d5, rebuilt json-c and after that I was able to link my program with it successfully.

As @guru-florida suggested in Issue #308: Why not just switch to CMake? It isnt that hard to setup and I find real cmake builds always work and autoconf is usually a PITA.

https://github.com/guru-florida/json-c

I'm expecting to merge over these changes after the next json-c release. (See Issue #314)

We have seen twice now error messages where json-c has failed parsing a json file written by the same app (and thus json-c). In both cases the files got invalid syntax, as one double value had not been serialized, like the missing width value in the example below.

.... “size”: { “width”: , “height”: 0.5 }, ....

It happens very seldom, and was detected by automated testing in both cases.

Hi, I have a json child node object that originates in a given parent object. This node gets added, as a child node, a number of times (using pointer reference) to other json objects. Each of one of those "other" objects gets a "put" as they get terminated. Finally, the parent also gets a "put" at the end of the cycle. I seem to get random crashes under this scenario. What's the correct way to handle the above?

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffebfff700 (LWP 5190)] 0x00007fffec0827f8 in ?? () (gdb) where #0 0x00007fffec0827f8 in ?? () #1 0x00007ffff75967ce in json_object_put (jso=0x7fffec0827f0) at json_object.c:158 #2 json_object_put (jso=0x7fffec0827f0) at json_object.c:150 #3 0x00007ffff759a3f6 in lh_table_free (t=0x7fffec153150) at linkhash.c:485 #4 0x00007ffff759672d in json_object_object_delete (jso=0x7fffec153100)

at json_object.c:354

#5 0x00007ffff75967d4 in json_object_put (jso=0x7fffec153100) at json_object.c:159 #6 json_object_put (jso=0x7fffec153100) at json_object.c:150 #7 0x000000000043310c in proto_http_reset_session_callback (sesn_ptr=0x794db0,

callflags=1) at protocol_http.c:220

#8 0x000000000043f4f3 in SuspendThisSession (sesn_ptr_this=0x0,

sesn_ptr_target=0x794db0, recycle_flag=1) at session.c:353

#9 0x0000000000444f5e in CheckSessionIdleTime (arg=0x7c70d0) at session.c:3389 #10 0x0000000000465d42 in ThreadUFServerWorker (ptr=0x6d4b00)

at worker_ufsrv_thread.c:188

#11 0x00007ffff79bbb50 in start_thread (arg=) at pthread_create.c:304 #12 0x00007ffff5d3395d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #13 0x0000000000000000 in ?? ()

I tried running tests with wine with the make check build, and ran into some issues.

With these changes it worked: https://gist.github.com/braydonf/41091d8a63d111aa2d954dccb1ad0d56

Hello,

It's difficult to determine when to call json_object_put after json_obect_xxx calls. I found tons of questions about this and all examples and tutorials I found really don't care about correctly freeing the memory. And answers and not allways clear as it seems that doubts are widely shared.

One example about json_object_parse_ex in your documentation, you effectively specify that an object is returned so we can logically think that a call to json_object_put is necessary but a clearer notice would be fine all the more the given code snippet doesn't mention json_object_put call. Maybe json_object_put documentation could give the list of the functions supposed to need this call. I understand it's maybe not so simple as some functions transfer ownership and so, if I well understand because it's also not so obvious, doesn't wait from freeing the object from theirself.

What json_tokener_freedo ??

Some functions increment ownership such as json_object_get is it the only one? Can json_object_get be called other function, like json_tokern_parse for example? And so is there an json_object_count to call json_object_put until 0?

Often, functions which doesn't change increment count specify that there is no need to call json_object_put except for special situation. But the ones which need it don't tell anything such as json_object_get even if it souds obvious for you.

And itseems that the documentation refers to 0.10 version.

Thanks in advance.

I am using v0.12.1. I am seeing that very large strings are causing the tokener code to hang. I'm not exactly sure what the size cutoff is that is causing the issue because I don't control the code sending the messages. I have seen packets 300-500 bytes/characters long. The string that I"m working on now though is 1298 bytes/characters.

Is there a max length that is supported by json_c?

Here is a snippet of my code and where things hang up:

    json_tokener* tok;
    tok = json_tokener_new();
    jsonObj = json_tokener_parse_ex(tok, i_strToParse, i_length);

Initially I had this, which worked for the smaller strings. jsonObj = json_tokener_parse( i_strToParse );

I even tried calling json_tokener_new_ex() and passing a specific depth thinking that possibly it was allocating too much space. That made no difference.

I have to be doing something wrong, but I'm not sure what. The above code works for all of the other strings that I am trying to parse. Any help/guidance is appreciated.

Feature Request When json-c converts a json array to a json string and the flag 'JSON_C_TO_STRING_PRETTY' is used, it inserts a newline after every array element.

If the array is a long array filled with integers, it can be tedious to scroll down to view the entire array.
A good solution would be to use the default flag 'JSON_C_TO_STRING_PLAIN' to print the array all on one line. But if the array is nested within a json object that includes other objects that are not arrays then the 'JSON_C_TO_STRING_PRETTY' flag seems to be needed to preserve the pretty formatting for the other objects.

Example:

{
  "test1":{
    "test2":{
      "test3":"test3"
    }
  },
  "my_long_array":[
    0,
    1,
    2,
    3,
    4,
    5,
<snip>
    250,
    251,
    252,
    253,
    254
  ]
}

Steps To Reproduce

json_object *parent = json_object_new_object();
struct json_object *test1 = json_object_new_object();
struct json_object *test2 = json_object_new_object();
json_object_object_add(test2, "test3", json_object_new_string("test3"));
json_object_object_add(test1, "test2", test2);
json_object_object_add(parent, "test1", test1);

json_object *my_long_array = json_object_new_array();
for (int i = 0; i < 255; i++)
	json_object_array_add(my_long_array, json_object_new_int(i));
json_object_object_add(parent, "my_long_array", my_long_array);

printf("%s\n", json_object_to_json_string_ext(parent, JSON_C_TO_STRING_PRETTY));

Would it be possible to have a new pretty-print format that prints n-number of array elements per line? While still preserving pretty format for the non-array objects within an object? So the result would look something like this:

{
  "test1":{
    "test2":{
      "test3":"test3"
    }
  },
  "my_long_array":[
    0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,
    30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,
    57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,
    84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,
    108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,
    128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,
    148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,
    168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,
    188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,
    208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,
    228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,
    248,249,250,251,252,253,254
    ]
}

Version and Platform

• json-c version: json-c 0.16-1
• OS: Arch
• Custom cmake/build flags: none

Struct 'json_object' forward declaration unnecessary, already declared. Please delete it. According to standards for C Language, high Risk to use strcat() in json_object.c . It should be replaced by strncat. High Risk to use vsprintf(). It should be replaced by vsnprintf.

Describe the bug Will not build with CMAKE prior to version 2.8.12

Steps To Reproduce Try to build with version CMAKE < 2.8.12

Version and Platform

• json-c version: [e.g. json-c-0.15, or a specific commit hash]
• OS: [e.g. Ubuntu 18.04.6, ]
• cmake version 2.8.4

This option enable color in json_object_to_json_string_ext. I've try to made something similar to jq output, but I color true/false and null in purple, as it's what is common color scheme used in programing language in emacs.

also add a '-c' option into json_parser to test it.

note: that I could have done a color() function similar to what is done with indent(), but as the code is pretty small I've keep it as it. so if you want me to use a subfunction tell me and I'll do it.

Signed-off-by: Matthias Gatto [email protected]

Note: for general questions and comments, please use the forums at: https://groups.google.com/g/json-c

Describe the bug On some systems, json-c uses arc4random(), but then the linker fails to find it. See e.g. messages from @nmartin-cs and @moonburnt at https://github.com/json-c/json-c/issues/692#issuecomment-793057630

Steps To Reproduce

mkdir build && cd $_
cmake ..
cmake -DCMAKE_INSTALL_PREFIX=/usr .
sudo make install  

Version and Platform Arch Linux 5.10.13, glibc 2.33-3, gcc 10.2.0, cmake

Do not silently truncate values or skip entries if out of memory errors occur.

Proof of Concept:

• Create poc.c, a program which creates an eight megabyte large json object with key "A" and a lot of "B"s as value, one of them is UTF-formatted:

 #include <err.h>
 #include <stdio.h>
 #include <string.h>

 #include "json.h"

 #define STR_LEN (8 * 1024 * 1024)
 #define STR_PREFIX "{ \"A\": \""
 #define STR_SUFFIX "\\u0042\" }"

int main(void) {
  char *str;
  struct json_tokener *tok;
  struct json_object *obj;

  if ((tok = json_tokener_new()) == NULL)
    errx(1, "json_tokener_new");

  if ((str = malloc(STR_LEN)) == NULL)
    err(1, "malloc");
  memset(str, 'B', STR_LEN);
  memcpy(str, STR_PREFIX, sizeof(STR_PREFIX) - 1);
  memcpy(str + STR_LEN - sizeof(STR_SUFFIX), STR_SUFFIX, sizeof(STR_SUFFIX));

  obj = json_tokener_parse(str);
  free(str);

  printf("%p\n", obj);
  if (obj != NULL) {
    printf("%.*s\n", 50, json_object_to_json_string(obj));
    json_object_put(obj);
  }

  json_tokener_free(tok);
  return 0;
}

• Compile and run poc, assuming you have enough free heap space:

gcc $(pkg-config --cflags --libs) -o poc poc.c
./poc
0x559421e15de0
{ "A": "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB

• Reduce available heap and run again, which leads to truncation:

ulimit -d 10000
./poc
0x555a5b453de0
{ "A": "B" }

• Compile json-c with this change and run with reduced heap again:

ulimit -d 10000
./poc
(nil)

The output is limited to 50 characters, i.e. json-c parses the 8 MB string correctly but the poc does not print all of them to the screen.

The truncation occurs because the parser tries to add all chars up to the UTF-8 formatted 'B' at once. Since memory is limited to 10 MB there is not enough for this operation. The parser does not fail but continues normally.

Another possibility is to create a json file close to 2 GB and run a program on a system with limited amount of RAM, i.e. around 3 GB. But ulimit restrictions are much easier for proof of concepts.

Treat memory errors correctly and abort operations.