Giter Club home page Giter Club logo

json-c's Introduction

\mainpage

json-c

  1. Overview and Build Status
  2. Getting Help
  3. Building on Unix
  4. CMake options
  5. Testing
  6. Building with vcpkg
  7. Building for Android
  8. Linking to libjson-c
  9. Using json-c

JSON-C - A JSON implementation in C

JSON-C implements a reference counting object model that allows you to easily construct JSON objects in C, output them as JSON formatted strings and parse JSON formatted strings back into the C representation of JSON objects. It aims to conform to RFC 8259.

Skip down to Using json-c or check out the API docs, if you already have json-c installed and ready to use.

Home page for json-c: https://github.com/json-c/json-c/wiki

Getting Help

If you have questions about using json-c, please start a thread on our forums at: https://groups.google.com/forum/#!forum/json-c

If you believe you've discovered a bug, report it at (https://github.com/json-c/json-c/issues). Please be sure to include the version of json-c you're using, the OS you're running on, and any other relevant details. Fully reproducible test cases and/or patches to fix problems are greatly appreciated.

Fixes for bugs, or small new features can be directly submitted as a pull request. For major new features or large changes of any kind, please first start a discussion on the forums.

Building on Unix with git, gcc and cmake

If you already have json-c installed, see Linking to libjson-c for how to build and link your program against it.

Build Status

Test Status

Prerequisites:

  • gcc, clang, or another C compiler

  • cmake>=2.8, >=3.16 recommended, cmake=>3.1 for tests

To generate docs you'll also need:

  • doxygen>=1.8.13

If you are on a relatively modern system, you'll likely be able to install the prerequisites using your OS's packaging system.

Install using apt (e.g. Ubuntu 16.04.2 LTS)

sudo apt install git
sudo apt install cmake
sudo apt install doxygen  # optional
sudo apt install valgrind # optional

Build instructions:

json-c GitHub repo: https://github.com/json-c/json-c

$ git clone https://github.com/json-c/json-c.git
$ mkdir json-c-build
$ cd json-c-build
$ cmake ../json-c   # See CMake section below for custom arguments

Note: it's also possible to put your build directory inside the json-c source directory, or even not use a separate build directory at all, but certain things might not work quite right (notably, make distcheck)

Then:

$ make
$ make test
$ make USE_VALGRIND=0 test   # optionally skip using valgrind
$ sudo make install          # it could be necessary to execute make install

Generating documentation with Doxygen:

The library documentation can be generated directly from the source code using Doxygen tool:

# in build directory
make doc
google-chrome doc/html/index.html

CMake Options

The json-c library is built with CMake, which can take a few options.

Variable Type Description
CMAKE_INSTALL_PREFIX String The install location.
CMAKE_BUILD_TYPE String Defaults to "debug".
BUILD_SHARED_LIBS Bool The default build generates a dynamic (dll/so) library. Set this to OFF to create a static library only.
BUILD_STATIC_LIBS Bool The default build generates a static (lib/a) library. Set this to OFF to create a shared library only.
DISABLE_STATIC_FPIC Bool The default builds position independent code. Set this to OFF to create a shared library only.
DISABLE_BSYMBOLIC Bool Disable use of -Bsymbolic-functions.
DISABLE_THREAD_LOCAL_STORAGE Bool Disable use of Thread-Local Storage (HAVE___THREAD).
DISABLE_WERROR Bool Disable use of -Werror.
DISABLE_EXTRA_LIBS Bool Disable use of extra libraries, libbsd
DISABLE_JSON_POINTER Bool Omit json_pointer support from the build.
ENABLE_RDRAND Bool Enable RDRAND Hardware RNG Hash Seed.
ENABLE_THREADING Bool Enable partial threading support.
OVERRIDE_GET_RANDOM_SEED String A block of code to use instead of the default implementation of json_c_get_random_seed(), e.g. on embedded platforms where not even the fallback to time() works. Must be a single line.

Pass these options as -D on CMake's command-line.

# build a static library only
cmake -DBUILD_SHARED_LIBS=OFF ..

Building with partial threading support

Although json-c does not support fully multi-threaded access to object trees, it has some code to help make its use in threaded programs a bit safer. Currently, this is limited to using atomic operations for json_object_get() and json_object_put().

Since this may have a performance impact, of at least 3x slower according to https://stackoverflow.com/a/11609063, it is disabled by default. You may turn it on by adjusting your cmake command with: -DENABLE_THREADING=ON

Separately, the default hash function used for object field keys, lh_char_hash, uses a compare-and-swap operation to ensure the random seed is only generated once. Because this is a one-time operation, it is always compiled in when the compare-and-swap operation is available.

cmake-configure wrapper script

For those familiar with the old autoconf/autogen.sh/configure method, there is a cmake-configure wrapper script to ease the transition to cmake.

mkdir build
cd build
../cmake-configure --prefix=/some/install/path
make

cmake-configure can take a few options.

options Description
prefix=PREFIX install architecture-independent files in PREFIX
enable-threading Enable code to support partly multi-threaded use
enable-rdrand Enable RDRAND Hardware RNG Hash Seed generation on supported x86/x64 platforms.
enable-shared build shared libraries [default=yes]
enable-static build static libraries [default=yes]
disable-Bsymbolic Avoid linking with -Bsymbolic-function
disable-werror Avoid treating compiler warnings as fatal errors

Testing:

By default, if valgrind is available running tests uses it. That can slow the tests down considerably, so to disable it use:

export USE_VALGRIND=0

To run tests a separate build directory is recommended:

mkdir build-test
cd build-test
# VALGRIND=1 causes -DVALGRIND=1 to be passed when compiling code
# which uses slightly slower, but valgrind-safe code.
VALGRIND=1 cmake ..
make

make test
# By default, if valgrind is available running tests uses it.
make USE_VALGRIND=0 test   # optionally skip using valgrind

If a test fails, check Testing/Temporary/LastTest.log, tests/testSubDir/${testname}/${testname}.vg.out, and other similar files. If there is insufficient output try:

VERBOSE=1 CTEST_OUTPUT_ON_FAILURE=1 make test

or

JSONC_TEST_TRACE=1 make test

and check the log files again.

Building on Unix and Windows with vcpkg

You can download and install JSON-C using the vcpkg dependency manager:

git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
vcpkg install json-c

The JSON-C port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.

Building for Android ----------------------

Building on Android is now particularly well supported, but there have been some reports of success using https://developer.android.com/ndk/guides/cmake

mkdir json-c-build
cd json-c-build/
export NDK_HOME=~/Library/Android/sdk/ndk/22.1.7171670/
cmake \
    --toolchain=$NDK_HOME/build/cmake/android.toolchain.cmake \
    -DANDROID_STL=none \
    -DANDROID_ABI=arm64-v8a \
    -DANDROID_PLATFORM=android-29 \
    -DANDROID_LD=lld \
    -DCMAKE_BUILD_TYPE=MinSizeRel \
    -DCMAKE_INSTALL_PREFIX=<install prefix> \
    -DENABLE_THREADING=true \
    ..
make install
Linking to `libjson-c` ----------------------

If your system has pkgconfig, then you can just add this to your makefile:

CFLAGS += $(shell pkg-config --cflags json-c)
LDFLAGS += $(shell pkg-config --libs json-c)

Without pkgconfig, you might do something like this:

JSON_C_DIR=/path/to/json_c/install
CFLAGS += -I$(JSON_C_DIR)/include/json-c
# Or to use lines like: #include <json-c/json_object.h>
#CFLAGS += -I$(JSON_C_DIR)/include
LDFLAGS+= -L$(JSON_C_DIR)/lib -ljson-c

If your project uses cmake:

  • Add to your CMakeLists.txt file:
find_package(json-c CONFIG)
target_link_libraries(${PROJECT_NAME} PRIVATE json-c::json-c)
  • Then you might run in your project:
cd build
cmake -DCMAKE_PREFIX_PATH=/path/to/json_c/install/lib64/cmake ..
Using json-c ------------

To use json-c you can either include json.h, or preferably, one of the following more specific header files:

  • json_object.h - Core types and methods.
  • json_tokener.h - Methods for parsing and serializing json-c object trees.
  • json_pointer.h - JSON Pointer (RFC 6901) implementation for retrieving objects from a json-c object tree.
  • json_object_iterator.h - Methods for iterating over single json_object instances. (See also json_object_object_foreach() in json_object.h)
  • json_visit.h - Methods for walking a tree of json-c objects.
  • json_util.h - Miscellaneous utility functions.

For a full list of headers see files.html

The primary type in json-c is json_object. It describes a reference counted tree of json objects which are created by either parsing text with a json_tokener (i.e. json_tokener_parse_ex()), or by creating (with json_object_new_object(), json_object_new_int(), etc...) and adding (with json_object_object_add(), json_object_array_add(), etc...) them individually. Typically, every object in the tree will have one reference, from its parent. When you are done with the tree of objects, you call json_object_put() on just the root object to free it, which recurses down through any child objects calling json_object_put() on each one of those in turn.

You can get a reference to a single child (json_object_object_get() or json_object_array_get_idx()) and use that object as long as its parent is valid.
If you need a child object to live longer than its parent, you can increment the child's refcount (json_object_get()) to allow it to survive the parent being freed or it being removed from its parent (json_object_object_del() or json_object_array_del_idx())

When parsing text, the json_tokener object is independent from the json_object that it returns. It can be allocated (json_tokener_new()) used one or multiple times (json_tokener_parse_ex(), and freed (json_tokener_free()) while the json_object objects live on.

A json_object tree can be serialized back into a string with json_object_to_json_string_ext(). The string that is returned is only valid until the next "to_json_string" call on that same object. Also, it is freed when the json_object is freed.

json-c's People

Contributors

andy5995 avatar besser82 avatar commodo avatar darjankrijan avatar derdakon avatar dota17 avatar emielbruijntjes avatar evo-i avatar haffon avatar hawicz avatar hofnarrr avatar jamesmyatt avatar jehiah avatar jobol avatar lespocky avatar michaeljclark avatar mloskot avatar neocturne avatar ploxiln avatar ramiropolla avatar remicollet avatar rgerhards avatar robiwano avatar rouault avatar sgerbino avatar sixlettervariables avatar ssrlive avatar stoeckmann avatar thecount avatar yrashk avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

json-c's Issues

doesn't compile on OS X: Unknown psuedo-op: .pushsection

git clone git://github.com/json-c/json-c.git
cd json-c
sh autogen.sh
./configure
make
 ...

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT libjson.lo -MD -MP -MF .deps/libjson.Tpo -c libjson.c  -fno-common -DPIC -o .libs/libjson.o
/var/folders/g_/p4f7b2154hn0v1pg2qghv1xm0000gn/T//ccmSROut.s:3:Unknown pseudo-op: .pushsection
/var/folders/g_/p4f7b2154hn0v1pg2qghv1xm0000gn/T//ccmSROut.s:3:Rest of line ignored. 1st junk character valued 46 (.).
/var/folders/g_/p4f7b2154hn0v1pg2qghv1xm0000gn/T//ccmSROut.s:5:Unknown pseudo-op: .popsection

json_tokener_parse() returns invalid (uninitialized?) value in case of malformed JSON.

Version:

json-c-0.9                     JSON (JavaScript Object Notation) implementation in C

Code snippet:

    json_tokener * jtok = json_tokener_new();
    json_object * obj = json_tokener_parse_ex(jtok, "", 0);
    printf("json_tokener_parse_ex: 0x%08X\n", obj);
    json_tokener_free(jtok);
    obj = json_tokener_parse("");
    printf("json_tokener_parse: 0x%08X\n", obj);

Output:

json_tokener_parse_ex: 0x00000000
json_tokener_parse: 0xFFFFFFFD

Unfortunately have no way to update library to check if it's still an issue in the newest releases.

Fail 'make check' at test_null

$ VERBOSE=1 make check
(snip)
=== Running test test_null.test
ERROR: "test_null " (test_null) failed (set VERBOSE=1 to see full output):
+ diff /tmp/json-c/tests/test_null.expected testSubDir/test_null.test/test_null.out
2a3
> Re-parsed object string len=3, chars=[32, 0, 32]
cp "testSubDir/test_null.test/test_null.out" "/tmp/json-c/tests/test_null.expected"
FAIL: test_null.test
(snip)
========================================
1 of 10 tests failed

Parsing incorrect when braces or brackets are missing

When there are no braces or brackets around a JSON data the parser returns a valid struct. Also is_error does not report an error. The parsing only parses the first string or value within the JSON data and then returns.
When an object is requested the application crashes (on Linux with a segfault) in lh_table_lookup_entry.

We changed the following line of code in json_tokener_parse_ex:

  if(tok->err == json_tokener_success) return json_object_get(current);

to:

  if(tok->err == json_tokener_success) 
  {
      /* 
      *  Parser doesn't report an error if the root object is not of type object or array.
      */
      json_object* obj = json_object_get(current);
      if (json_object_is_type(obj, json_type_object) || json_object_is_type(obj, json_type_array))
      {
          return obj;
      }
      else
      {
          tok->err = json_tokener_error_parse_string;
      }
  }

This code makes sure that the root object is of type object or array.

json_object_traverse

I appreciate the flexible iterator provided by json-c, but I've found my callback based traversal wrapper to be very convenient. Perhaps someone else would as well. Would a pull request for this be accepted?

Implementation:

typedef int (*json_object_iter_cb)(const char* key, struct json_object* value, void *userdata);

int json_object_traverse(struct json_object *o, json_object_iter_cb cb, void *userdata)
{
    struct json_object_iterator it = json_object_iter_begin(o);
    struct json_object_iterator itEnd = json_object_iter_end(o);
    while (!json_object_iter_equal(&it, &itEnd)) {
        int retval = cb(json_object_iter_peek_name(&it), json_object_iter_peek_value(&it), userdata);
        if (retval != 0) {
            return retval;
        }
        json_object_iter_next(&it);
    }
    return 0;
}

Usage:

int print_key(const char* key, struct json_object* value, void *userdata)
{
    printf("%s\n", key);
    return 0;
}

void main()
{
    struct json_object* obj = json_tokener_parse("{'first':'george', 'age':100}");
    json_object_traverse(obj, print_key, NULL);
}

failed to install-data-hook, it should add -rf to rm

make install-data-hook
make[4]: Entering directory `/tmp/json-c-0.11'
test ! -e "/usr/include/json" || rm "/usr/include/json"
rm: cannot remove ‘/usr/include/json’: Is a directory
make[4]: *** [install-data-hook] Error 1

json-c-0.11/Makefile.in + 975

  • @ENABLE_OLDNAME_COMPAT_TRUE@ test ! -e "$(DESTDIR)@includedir@/json" || rm "$(DESTDIR)@includedir@/json"
  • @ENABLE_OLDNAME_COMPAT_TRUE@ test ! -e "$(DESTDIR)@includedir@/json" || rm -rf "$(DESTDIR)@includedir@/json"

json_tokener_parse() return success in some bad cases, and it leads to core dump, is it a bug ?

json_tokener_parse() cannot print a warning info when the given string begins with '0' ~ '9' (ascii code range: 0x30 - 0x39).
the following code show the bad case:
char json_str[] = {0x30, '{', '}', '\0'};
struct json_object * root_obj;
root_obj = json_tokener_parse(json_str);
if(NULL == root_obj || is_error(root_obj)) { // here, no warning info thrown to user, everything seems ok
printf("json_tokener_parse() failed, root_obj=0x%x\n", root_obj);
return -1;
}

struct json_object * pcid_obj = NULL;
pcid_obj = json_object_object_get(root_obj, "pcid"); // here, core dump would happen
if(is_error(pcid_obj)) {
printf("parse 'pcid' failed, pcid_obj=0x%x\n", pcid_obj);
return -1;
}

from codes showed above, we can see: a invalid json string is passed to json_tokener_parse(), but no warning thrown from return code, is it normal ?

Empty strings and unicode zero values break json parsing.

Forwarded from http://bugs.debian.org/687269, reported by Vincent Sanders <[email protected]>:

Package: libjson0
Version: 0.10-1.1
Severity: important

If the input JSON contains empty value (i.e. "") The internal string
buffer is unterminated and unexpected behaviour occours.

If the unicode value \u0000 appears in the input the string is
terminated early and the string is truncated.

The attached patch fixes these issues.

Index: json-c-0.10/json_object.c
===================================================================
--- json-c-0.10.orig/json_object.c  2012-04-29 10:55:43.000000000 -0700
+++ json-c-0.10/json_object.c   2012-08-30 11:26:08.000000000 -0700
@@ -531,8 +531,9 @@
   if(!jso) return NULL;
   jso->_delete = &json_object_string_delete;
   jso->_to_json_string = &json_object_string_to_json_string;
-  jso->o.c_string.str = malloc(len);
+  jso->o.c_string.str = malloc(len + 1);
   memcpy(jso->o.c_string.str, (void *)s, len);
+  jso->o.c_string.str[len] = '\0';
   jso->o.c_string.len = len;
   return jso;
 }
Index: json-c-0.10/json_tokener.c
===================================================================
--- json-c-0.10.orig/json_tokener.c 2012-04-29 10:55:43.000000000 -0700
+++ json-c-0.10/json_tokener.c  2012-08-30 11:22:29.000000000 -0700
@@ -387,7 +387,7 @@
    while(1) {
      if(c == tok->quote_char) {
        printbuf_memappend_fast(tok->pb, case_start, str-case_start);
-       current = json_object_new_string(tok->pb->buf);
+       current = json_object_new_string_len(tok->pb->buf, tok->pb->bpos);
        saved_state = json_tokener_state_finish;
        state = json_tokener_state_eatws;
        break;

(I'm not sure about the validity of the report, but it surely isn't a problem with Debian's packaging, and may indicate something about the documentation, so...)

Failed to build in ansi mode

Failed to build in ansi mode.
C++ style comment at very end of json_object_iterator.h causes error.

#endif // JSON_OBJECT_ITERATOR_H

must be replaced to:

#endif /* JSON_OBJECT_ITERATOR_H */

make check fails compilation

Hello, I am trying to compile postgis 2.0.2, which depends on json-c, and the json-c "make test" step fails because of the -Werror compile directive.

"git show" at this time gives:

commit bfb3292
Author: Eric Haszlakiewicz [email protected]
Date: Sat Feb 9 17:35:33 2013 -0600
...

Full message of the second run of "make check" is as follows:

root@geo:~/json-c# make check
Making check in .
make[1]: Entering directory /root/json-c' make[1]: Leaving directory/root/json-c'
Making check in tests
make[1]: Entering directory /root/json-c/tests' make test1 test1Formatted test2 test2Formatted test4 testReplaceExisting test_parse_int64 test_null test_cast test_parse test_printbuf test_set_serializer make[2]: Entering directory/root/json-c/tests'
make[2]: test1' is up to date. make[2]:test1Formatted' is up to date.
make[2]: test2' is up to date. make[2]:test2Formatted' is up to date.
make[2]: test4' is up to date. gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter -std=c99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT testReplaceExisting.o -MD -MP -MF .deps/testReplaceExisting.Tpo -c -o testReplaceExisting.o testReplaceExisting.c testReplaceExisting.c: In function ‘main’: testReplaceExisting.c:57:2: error: variable ‘val2’ set but not used [-Werror=unused-but-set-variable] testReplaceExisting.c:56:6: error: variable ‘retval’ set but not used [-Werror=unused-but-set-variable] testReplaceExisting.c:42:2: error: variable ‘val’ set but not used [-Werror=unused-but-set-variable] testReplaceExisting.c:25:2: error: variable ‘val0’ set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors make[2]: *** [testReplaceExisting.o] Error 1 make[2]: Leaving directory/root/json-c/tests'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/root/json-c/tests'
make: *** [check-recursive] Error 1

json-c's libjson.so library conflicts with other json libraries

The use of "libjson.so" (and symlinks libjson.so.0, etc...) for the json-c library can lead to conflicts because other people have used the same, rather generic name for their libraries.
The solution for this is fairly obvious, rename it to something like libjson-c.so.
In addition to renaming the library we probably want to rename the include directory:
include/json/json.h ==> include/json-c/json.h

Of course, there still might be conflicts if you try to use two json libraries in the same program, but that's a considerably more difficult fix.

failure to build with multiple jobs

Project fails to build if you specify multiple jobs for make:

$ make -j8 ..... /bin/bash ./libtool --tag=CC --mode=link gcc -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -version-info 1:0:1 -no-undefined -ljson-c -o libjson.la -rpath /home/dem/devel/json/json-c/deploy/lib libjson.lo -ljson-c libtool: compile: gcc -DHAVE_CONFIG_H -I. -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT printbuf.lo -MD -MP -MF .deps/printbuf.Tpo -c printbuf.c -o printbuf.o >/dev/null 2>&1 libtool: compile: gcc -DHAVE_CONFIG_H -I. -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT json_object.lo -MD -MP -MF .deps/json_object.Tpo -c json_object.c -o json_object.o >/dev/null 2>&1 mv -f .deps/json_util.Tpo .deps/json_util.Plo mv -f .deps/printbuf.Tpo .deps/printbuf.Plo libtool: link: gcc -shared -fPIC -DPIC .libs/libjson.o -ljson-c -O2 -Wl,-soname -Wl,libjson.so.0 -o .libs/libjson.so.0.1.0 /usr/bin/ld: cannot find -ljson-c collect2: ld returned 1 exit status make[2]: *** [libjson.la] Error 1 make[2]: *** Waiting for unfinished jobs.... mv -f .deps/linkhash.Tpo .deps/linkhash.Plo mv -f .deps/json_object.Tpo .deps/json_object.Plo libtool: compile: gcc -DHAVE_CONFIG_H -I. -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT json_tokener.lo -MD -MP -MF .deps/json_tokener.Tpo -c json_tokener.c -o json_tokener.o >/dev/null 2>&1 mv -f .deps/json_tokener.Tpo .deps/json_tokener.Plo make[2]: Leaving directory /home/dem/devel/json/json-c'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory /home/dem/devel/json/json-c' make: *** [all] Error 2

"./configure ; make distclean" deletes ./configure

Config: json-c-0.10.tar.gz release

Steps:
1.) Unzip the sources.
2.) cd into the source directory and run "./configure ; make distclean"
3.) Run "./configure".

Expected behavior:
./configure should still exist after "make distclean".

Observed behavior:
./configure no longer exists, so have to delete the directory and re-unzip json-c-0.10.tar.gz. I've included a console log below:

Haugheys-Mac-Mini:install haughey_media$ tar zxfv json-c-0.10.tar.gz
x json-c-0.10
x json-c-0.10/.gitignore
x json-c-0.10/AUTHORS
x json-c-0.10/COPYING
x json-c-0.10/ChangeLog
x json-c-0.10/Doxyfile
x json-c-0.10/INSTALL
x json-c-0.10/Makefile.am
x json-c-0.10/Makefile.am.inc
x json-c-0.10/NEWS
x json-c-0.10/README
x json-c-0.10/README-WIN32.html
x json-c-0.10/README.html
x json-c-0.10/RELEASE_CHECKLIST.txt
x json-c-0.10/arraylist.c
x json-c-0.10/arraylist.h
x json-c-0.10/autogen.sh
x json-c-0.10/bits.h
x json-c-0.10/config.h.in
x json-c-0.10/config.h.win32
x json-c-0.10/configure.in
x json-c-0.10/debug.c
x json-c-0.10/debug.h
x json-c-0.10/json-c.vcproj
x json-c-0.10/json.h
x json-c-0.10/json.pc.in
x json-c-0.10/json_config.h.in
x json-c-0.10/json_inttypes.h
x json-c-0.10/json_object.c
x json-c-0.10/json_object.h
x json-c-0.10/json_object_iterator.c
x json-c-0.10/json_object_iterator.h
x json-c-0.10/json_object_private.h
x json-c-0.10/json_tokener.c
x json-c-0.10/json_tokener.h
x json-c-0.10/json_util.c
x json-c-0.10/json_util.h
x json-c-0.10/linkhash.c
x json-c-0.10/linkhash.h
x json-c-0.10/printbuf.c
x json-c-0.10/printbuf.h
x json-c-0.10/tests
x json-c-0.10/tests/Makefile.am
x json-c-0.10/tests/parse_flags.c
x json-c-0.10/tests/parse_flags.h
x json-c-0.10/tests/parse_int64.test
x json-c-0.10/tests/test-defs.sh
x json-c-0.10/tests/test1.c
x json-c-0.10/tests/test1.expected
x json-c-0.10/tests/test1.test
x json-c-0.10/tests/test1Formatted_plain.expected
x json-c-0.10/tests/test1Formatted_pretty.expected
x json-c-0.10/tests/test1Formatted_spaced.expected
x json-c-0.10/tests/test2.c
x json-c-0.10/tests/test2.expected
x json-c-0.10/tests/test2.test
x json-c-0.10/tests/test2Formatted_plain.expected
x json-c-0.10/tests/test2Formatted_pretty.expected
x json-c-0.10/tests/test2Formatted_spaced.expected
x json-c-0.10/tests/test4.c
x json-c-0.10/tests/test4.expected
x json-c-0.10/tests/test4.test
x json-c-0.10/tests/test_cast.c
x json-c-0.10/tests/test_cast.expected
x json-c-0.10/tests/test_cast.test
x json-c-0.10/tests/test_null.c
x json-c-0.10/tests/test_null.expected
x json-c-0.10/tests/test_null.test
x json-c-0.10/tests/test_parse.c
x json-c-0.10/tests/test_parse.expected
x json-c-0.10/tests/test_parse.test
x json-c-0.10/tests/test_parse_int64.c
x json-c-0.10/tests/test_parse_int64.expected
x json-c-0.10/tests/test_printbuf.c
x json-c-0.10/tests/test_printbuf.expected
x json-c-0.10/tests/test_printbuf.test
x json-c-0.10/tests/Makefile.in
x json-c-0.10/Makefile.in
x json-c-0.10/aclocal.m4
x json-c-0.10/config.guess
x json-c-0.10/config.sub
x json-c-0.10/configure
x json-c-0.10/depcomp
x json-c-0.10/doc
x json-c-0.10/doc/html
x json-c-0.10/doc/html/annotated.html
x json-c-0.10/doc/html/arraylist_8h.html
x json-c-0.10/doc/html/bits_8h.html
x json-c-0.10/doc/html/classes.html
x json-c-0.10/doc/html/debug_8h.html
x json-c-0.10/doc/html/deprecated.html
x json-c-0.10/doc/html/doxygen.css
x json-c-0.10/doc/html/doxygen.png
x json-c-0.10/doc/html/files.html
x json-c-0.10/doc/html/functions.html
x json-c-0.10/doc/html/functions_vars.html
x json-c-0.10/doc/html/globals.html
x json-c-0.10/doc/html/globals_defs.html
x json-c-0.10/doc/html/globals_enum.html
x json-c-0.10/doc/html/globals_eval.html
x json-c-0.10/doc/html/globals_func.html
x json-c-0.10/doc/html/globals_type.html
x json-c-0.10/doc/html/globals_vars.html
x json-c-0.10/doc/html/index.html
x json-c-0.10/doc/html/json_8h.html
x json-c-0.10/doc/html/json__inttypes_8h.html
x json-c-0.10/doc/html/json__object_8h.html
x json-c-0.10/doc/html/json__object__iterator_8h.html
x json-c-0.10/doc/html/json__object__private_8h.html
x json-c-0.10/doc/html/json__tokener_8h.html
x json-c-0.10/doc/html/json__util_8h.html
x json-c-0.10/doc/html/linkhash_8h.html
x json-c-0.10/doc/html/pages.html
x json-c-0.10/doc/html/printbuf_8h.html
x json-c-0.10/doc/html/structarray__list.html
x json-c-0.10/doc/html/structjson__object.html
x json-c-0.10/doc/html/structjson__object__iter.html
x json-c-0.10/doc/html/structjson__object__iterator.html
x json-c-0.10/doc/html/structjson__tokener.html
x json-c-0.10/doc/html/tab_b.gif
x json-c-0.10/doc/html/structjson__tokener__srec.html
x json-c-0.10/doc/html/structlh__entry.html
x json-c-0.10/doc/html/structlh__table.html
x json-c-0.10/doc/html/structprintbuf.html
x json-c-0.10/doc/html/tab_l.gif
x json-c-0.10/doc/html/tab_r.gif
x json-c-0.10/doc/html/tabs.css
x json-c-0.10/doc/html/unionjson__object_1_1data.html
x json-c-0.10/install-sh
x json-c-0.10/ltmain.sh
x json-c-0.10/missing
Haugheys-Mac-Mini:install haughey_media$ cd json-c-0.10
Haugheys-Mac-Mini:json-c-0.10 haughey_media$ ./configure ; make distclean
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make sets $(MAKE)... (cached) yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking for strings.h... (cached) yes
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking for unistd.h... (cached) yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking stdarg.h usability... yes
checking stdarg.h presence... yes
checking for stdarg.h... yes
checking for inttypes.h... (cached) yes
checking for an ANSI C-conforming const... yes
checking for size_t... yes
checking for vprintf... yes
checking for _doprnt... no
checking for working memcmp... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible realloc... yes
checking for strndup... yes
checking for strerror... yes
checking for vsnprintf... yes
checking for vasprintf... yes
checking for open... yes
checking for vsyslog... yes
checking for strncasecmp... yes
checking build system type... x86_64-apple-darwin12.2.1
checking host system type... x86_64-apple-darwin12.2.1
checking for a sed that does not truncate output... /usr/bin/sed
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld
checking if the linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm
checking the name lister (/usr/bin/nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld option to reload object files... -r
checking for objdump... no
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm output from gcc object... ok
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin12.2.1 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating json.pc
config.status: creating tests/Makefile
config.status: creating config.h
config.status: creating json_config.h
config.status: executing depfiles commands
config.status: executing libtool commands
Making distclean in tests
rm -f test1 test1Formatted test2 test2Formatted test4 test_parse_int64 test_null test_cast test_parse test_printbuf
rm -rf .libs _libs
rm -f *.o
rm -f *.lo
rm -f *.tab.c
test -z "" || rm -f
test . = "." || test -z "" || rm -f
rm -rf testSubDir
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
rm -rf ./.deps
rm -f Makefile
Making distclean in .
test -z "libjson.la" || rm -f libjson.la
rm -f "./so_locations"
rm -rf .libs _libs
rm -f *.o
rm -f *.lo
rm -f *.tab.c
test -z "json.pc" || rm -f json.pc
test . = "." || test -z "" || rm -f
rm -f config.h stamp-h1 json_config.h stamp-h2
rm -f libtool config.lt
rm -rf
rm -rf config.h.in~ Makefile.in aclocal.m4 autom4te.cache/ config.guess config.sub configure depcomp install-sh ltmain.sh missing
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
rm -f config.status config.cache config.log configure.lineno config.status.lineno
rm -rf ./.deps
rm -f Makefile
Haugheys-Mac-Mini:json-c-0.10 haughey_media$ ./configure
-bash: ./configure: No such file or directory
Haugheys-Mac-Mini:json-c-0.10 haughey_media$

Unable to correctly parse timestamp from tracks.json message

Using the json c 0.9 library, and implemented the tracks processing section of the SpotterRF json examples. All the track fields are being parsed correctly except for timestamp. Print out of the received buffer from the radar has a valid Unix Epoch time in millilsecones for each track (like 1343999771499), but the json parser keeps returning 2147483647 (or 0x7fffffff which seems like an error flag) for timestamp. Implemented the follwing lines to extract timestamp:

unsigned long long trackTime;
struct json_object* timestamp = json_object_object_get(currrentTrack, 'timestamp");
trackTime = json_object_get_int(timestamp);

It appears the parser is not finding timestamp in the track message or is having an issue with the long long int value.

The Radar repoted buffer is as follows:

{"serial":"0427","userSession":"6218ed00-dd6d-11e1-ada7-cb96add778b9","timestamp":1343999771499,"errors":[],"success":true,"result":[{"id":"46","geolocation":{"latitude":27.775913,"longitude":-82.64061,"altitude":0,"accuracy":null,"altitudeAccuracy":null,"bearing":null,"heading":197.594742,"speed":2.977383},"observation":{"range":501.294383,"radialVelocity":1.479426,"horizontalAngle":9.072451,"azimuthAngle":9.072451,"verticalAngle":null,"altitudeAngle":null},"stats":{"rcs":2.193515},"timestamp":1343999766997},{"id":"46","geolocation":{"latitude":27.775896,"longitude":-82.640663,"altitude":0,"accuracy":null,"altitudeAccuracy":null,"bearing":null,"heading":197.932007,"speed":2.783555},"observation":{"range":502.25531,"radialVelocity":1.26217,"horizontalAngle":8.566077,"azimuthAngle":8.566077,"verticalAngle":null,"altitudeAngle":null},"stats":{"rcs":2.076364},"timestamp":1343999768141},{"id":"46","geolocation":{"latitude":27.775896,"longitude":-82.640663,"altitude":0,"accuracy":null,"altitudeAccuracy":null,"bearing":null,"heading":197.932007,"speed":2.783555},"observation":{"range":499.070007,"radialVelocity":1.26217,"horizontalAngle":8.566077,"azimuthAngle":8.566077,"verticalAngle":null,"altitudeAngle":null},"stats":{"rcs":2.076364},"timestamp":1343999769385},{"id":"46","geolocation":{"latitude":27.775883,"longitude":-82.640732,"altitude":0,"accuracy":null,"altitudeAccuracy":null,"bearing":null,"heading":198.085114,"speed":2.619313},"observation":{"range":493.545212,"radialVelocity":1.418029,"horizontalAngle":6.402413,"azimuthAngle":6.402413,"verticalAngle":null,"altitudeAngle":null},"stats":{"rcs":1.933511},"timestamp":1343999770406}]}

make test1 fails

The other tests: test2, test4, test_parse_in64, test_null, & test_cast, appear to compile. test1, however, goes as follows:

atom json-c # make test1
gcc -DHAVE_CONFIG_H -I.    -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT test1.o -MD -MP -MF .deps/test1.Tpo -c -o test1.o test1.c
cc1: warnings being treated as errors
test1.c: In function 'sort_fn':
test1.c:14: error: assignment discards qualifiers from pointer target type
test1.c:15: error: assignment discards qualifiers from pointer target type
make: *** [test1.o] Error 1
atom json-c # 

atom json-c # uname -a
Linux atom 2.6.36-gentoo-r5 #1 SMP Fri Jan 21 16:47:09 PST 2011 i686 Intel(R) Atom(TM) CPU D525 @ 1.80GHz GenuineIntel GNU/Linux
atom json-c #

I'm trying this library as I'm getting json-related error messages in building postgis (spatial database). On the off-chance the error I'm experiencing with my system json which is:

[I] dev-libs/json-c
     Available versions:  (~)0.9
     Installed versions:  0.9(20:18:52 11/25/11)
     Homepage:            http://oss.metaparadigm.com/json-c/
     Description:         A JSON implementation in C

touches on the test1 failure, I'll include the error output from the postgis tests:

psql:/usr/local/src/postgis-2.0.0SVN/regress/00-regress-install/postgis.sql:60: 
ERROR:  could not load library "/usr/local/src/postgis-2.0.0SVN/regress/00-regress-install/lib/postgis-2.0.so":
 /usr/local/src/postgis-2.0.0SVN/regress/00-regress-install/lib/postgis-2.0.so: undefined symbol: json_tokener_errors

Is the result of test1 a warning or an error?

inf and nan written out but cannot be read

I know that inf/nan are not strictly in the standard so supporting these values is not necessary but still others are doing it (e.g. python's json format by default).

The bug here with json-c is that it writes out inf and nan but cannot read these values back in.

Detected by serializing and de-serializing all of our shogun toolbox objects with json-c
shogun-toolbox/shogun#1464

json_object_from_file should not abort application on error

at current HEAD, a call to json_object_from_file(...) may abort the application.
i think a library should never terminate the calling application at all.

the provided patch fixes two things:

  • differentiate previously identical error messages
  • replace call to MC_ABORT with MC_ERROR. this will log an error, return NULL, but no more abort the calling application.

regards,
andi


diff -purN json-c-0.11/json_util.c json-c-0.11-patched/json_util.c
--- json-c-0.11/json_util.c 2013-04-01 04:01:09.000000000 +0200
+++ json-c-0.11-patched/json_util.c 2013-06-04 17:08:07.899604358 +0200
@@ -73,7 +73,7 @@ struct json_object* json_object_from_fil
int fd, ret;

if((fd = open(filename, O_RDONLY)) < 0) {

  • MC_ERROR("json_object_from_file: error reading file %s: %s\n",
  • MC_ERROR("json_object_from_file: error opening file %s: %s\n",
    filename, strerror(errno));
    return NULL;
    }
    @@ -87,7 +87,7 @@ struct json_object* json_object_from_fil
    }
    close(fd);
    if(ret < 0) {
  • MC_ABORT("json_object_from_file: error reading file %s: %s\n",
  • MC_ERROR("json_object_from_file: error reading file %s: %s\n",
    filename, strerror(errno));
    printbuf_free(pb);
    return NULL;

Tree should not contain generated files

Hey Eric,
IMO it doesn't really make sense to check in generate files into git (even if it's a separate release branch). The "correct" way to do it is just make all the changes for your release (including version bump in configure.ac), then run make dist to get a tarball.

This is pretty much the standard way to do things. Using the tree as it stands now means that autoreconf introduces changes to checked in files which is a bit ugly. Besides, doing it this way is probably a bigger maintenance hassle for you than is necessary.

Cheers,
Arun

`make check` of json-c-0.10 fails on Debian 4.4.5-8

After a smooth make using gcc 4.4.5 make check stops with following output
gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT test_printbuf.o -MD -MP -MF .deps/test_printbuf.Tpo -c -o test_printbuf.o test_printbuf.c
cc1: warnings being treated as errors
test_printbuf.c: In function ‘test_sprintbuf’:
test_printbuf.c:127: error: format ‘%d’ expects type ‘int’, but argument 5 has type ‘size_t’
make[2]: *** [test_printbuf.o] Fehler 1
make[2]: Leaving directory ./json-c-0.10/tests' make[1]: *** [check-am] Fehler 2 make[1]: Leaving directory./json-c-0.10/tests'
make: *** [check-recursive] Fehler 1

What's wrong? How can I fix this?

json-c defines "boolean", but so do other headers

json-c defines a C type boolean, but this conflicts with other headers (for example rpcndr.h in Windows) which define the same type. It seems like json-c should use json_boolean or something like that instead.

Missing stdint.h include in json_ojbect.h

The following patch is needed to compile cleanly (since json_object.h uses int32_t, etc.). I figure this is too trivial for a format-patch, but happy to provide one if preferred.

diff --git a/json_object.h b/json_object.h
index d56d12c..b4474f3 100644
--- a/json_object.h
+++ b/json_object.h
@@ -12,6 +12,8 @@
 #ifndef _json_object_h_
 #define _json_object_h_

+#include <stdint.h>
+
 #ifdef __cplusplus
 extern "C" {
 #endif

test1 fails

ERROR: "test1 " (test1) failed (set VERBOSE=1 to see full output):

diff /xxxxxx/json-c/tests/test1.expected testSubDir/test1.test/test1.out

30c30
< baz_obj.to_string()="fark"


baz_obj.to_string()="`[\u001b\u0002"

Use of "json" for headers and the library clashes with other implementations

When building large systems, using many third party components, it is not unusual to have a number of different JSON implementations. If more than one lays claim to the .../json directory name, then it is necessary to maintain a private fork to contain a modified set of build and install scripts/makefiles. A similar situation occurs with the use of libjson for the library.

json-c should use a unique name-space for its installed artifacts, preferably

.../include/json-c and
.../lib/libjson-c

Need "libtoolize" to build from git

I'm using OS X 10.6.8, with Apple's developer tools installed. I have libtool (as cited in the requirements for building when not using a release tarball), but not libtoolize (which isn't cited). Suggestion: add libtoolize to the requirements given when building without a release tarball.

Undefined symbol: json_object_from_file

All is already in the title, I just can put an example below:

➜ cfuu git:(master) make
gcc -W -Wall -pedantic -ansi -Wshadow -Werror -g -I/usr/local/include -c -o fuu.o fuu.c
gcc fuu.o -o fuu -L/usr/local/lib -ljson
➜ cfuu git:(master) ✗ ./fuu
./fuu: symbol lookup error: ./fuu: undefined symbol: json_object_from_file

I can assure that libraries are in /usr/local/lib and include <json/json.h> in /usr/local/include

Missing json_object_iterator

json_object_iterator .c is not listed in the libjson_la_SOURCES (Makefile.am) so is not built.

json_object_iterator .h have been added recently (not present in stable release)

Expose a version extraction method and macro

For compile-time and runtime version query.

This is to give LIBJSON its proper identification in PostGIS, for example:

 POSTGIS="2.0.2SVN r10248" GEOS="3.3.6dev-CAPI-1.7.6" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 2.0dev, released 2011/12/29" LIBXML="2.7.8" LIBJSON="UNKNOWN" 

Visual Studio 2010 does not provide inttypes.h

There is following condition in the json_inttypes.h:

#if defined(_MSC_VER) && _MSC_VER < 1600

/* Anything less than Visual Studio C++ 10 is missing stdint.h and inttypes.h */

It is incorrect. The Visual Studio 2010 (_MSC_VER 1600) does not provide inttypes.h header.
Chances are, next release of Visual Studio 11 (_MSC_VER 1700) will do.

So, the ifdef should be replaced with

#if defined(_MSC_VER) && _MSC_VER < 1700

json-c only produces 32-bit .so files?

I'm trying to make an RPM for json-c and json-c-devel for CentOS 5, 64-bit. However, when it gets installed it makes 32-bit .so files:

$ file libjson.so.0.1.0
libjson.so.0.1.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped

My version of ld will complain that it's not compatible and skips linking it when I try to build things using json-c-devel. So is there a 64-bit version, or am I doing things wrong?

(Sorry if this has been covered already in the docs; I haven't seen anything in the READMEs)

Problem with unicode characters containing capital letters in their hex number

Hi,

Parser seems to have problems with unicode characters like \u003C The capital C in the hex number causes the problem.

json-c version 0.9

include <json.h>

include <string.h>

include <assert.h>

int main(int argc, char** argv)
{
const char json[] = "{:"blah": "\u003Ca href"}";
json_tokener* tok = json_tokener_new();
assert(tok);
json_object* obj = json_tokener_parse_ex(tok, json, strlen(json));
assert(obj && !is_error(obj));
}

Simple fix/patch:
--- json-c-0.9/json_tokener.c 2009-07-31 02:10:16.000000000 +0000
+++ json-c-0.9/json_tokener.c.save 2011-06-07 16:12:10.000000000 +0000
@@ -406,7 +406,7 @@
{
/* Advance until we change state */
while(1) {

  •       if(strchr(json_hex_chars, c)) {
    
  •       if(strchr(json_hex_chars, tolower(c))) {
          tok->ucs_char += ((unsigned int)hexdigit(c) << ((3-tok->st_pos++)*4));
          if(tok->st_pos == 4) {
            unsigned char utf_out[3];
    

make check (0.10 tarball) failed

Trying to upgrade the old 0.9 release on openSUSE package I get an error on make check

Here the following extract
[ 38s] make[1]: Entering directory /home/abuild/rpmbuild/BUILD/json-c-0.10/tests' [ 38s] /usr/bin/make test1 test1Formatted test2 test2Formatted test4 test_parse_int64 test_null test_cast test_parse test_printbuf [ 38s] make[2]: Entering directory/home/abuild/rpmbuild/BUILD/json-c-0.10/tests'
[ 38s] gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -c test1.c
[ 38s] /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o test1 test1.o ../libjson.la
[ 38s] libtool: link: gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o .libs/test1 test1.o ../.libs/libjson.so -Wl,-rpath -Wl,/usr/lib64
[ 38s] gcc -DHAVE_CONFIG_H -I. -I.. -DTEST_FORMATTED -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -c -o test1Formatted-test1.o test -f 'test1.c' || echo './'test1.c
[ 38s] gcc -DHAVE_CONFIG_H -I. -I.. -DTEST_FORMATTED -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -c -o test1Formatted-parse_flags.o test -f 'parse_flags.c' || echo './'parse_flags.c
[ 38s] /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o test1Formatted test1Formatted-test1.o test1Formatted-parse_flags.o ../libjson.la
[ 38s] libtool: link: gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o .libs/test1Formatted test1Formatted-test1.o test1Formatted-parse_flags.o ../.libs/libjson.so -Wl,-rpath -Wl,/usr/lib64
[ 38s] gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -c test2.c
[ 38s] /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o test2 test2.o ../libjson.la
[ 38s] libtool: link: gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o .libs/test2 test2.o ../.libs/libjson.so -Wl,-rpath -Wl,/usr/lib64
[ 38s] gcc -DHAVE_CONFIG_H -I. -I.. -DTEST_FORMATTED -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -c -o test2Formatted-test2.o test -f 'test2.c' || echo './'test2.c
[ 38s] gcc -DHAVE_CONFIG_H -I. -I.. -DTEST_FORMATTED -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -c -o test2Formatted-parse_flags.o test -f 'parse_flags.c' || echo './'parse_flags.c
[ 38s] /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o test2Formatted test2Formatted-test2.o test2Formatted-parse_flags.o ../libjson.la
[ 38s] libtool: link: gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o .libs/test2Formatted test2Formatted-test2.o test2Formatted-parse_flags.o ../.libs/libjson.so -Wl,-rpath -Wl,/usr/lib64
[ 38s] gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -c test4.c
[ 39s] /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o test4 test4.o ../libjson.la
[ 39s] libtool: link: gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o .libs/test4 test4.o ../.libs/libjson.so -Wl,-rpath -Wl,/usr/lib64
[ 39s] gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -c test_parse_int64.c
[ 39s] /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o test_parse_int64 test_parse_int64.o ../libjson.la
[ 39s] libtool: link: gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o .libs/test_parse_int64 test_parse_int64.o ../.libs/libjson.so -Wl,-rpath -Wl,/usr/lib64
[ 39s] gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -c test_null.c
[ 39s] /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o test_null test_null.o ../libjson.la
[ 39s] libtool: link: gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o .libs/test_null test_null.o ../.libs/libjson.so -Wl,-rpath -Wl,/usr/lib64
[ 39s] gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -c test_cast.c
[ 39s] /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o test_cast test_cast.o ../libjson.la
[ 39s] libtool: link: gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o .libs/test_cast test_cast.o ../.libs/libjson.so -Wl,-rpath -Wl,/usr/lib64
[ 39s] gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -c test_parse.c
[ 39s] /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o test_parse test_parse.o ../libjson.la
[ 39s] libtool: link: gcc -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o .libs/test_parse test_parse.o ../.libs/libjson.so -Wl,-rpath -Wl,/usr/lib64
[ 39s] gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wwrite-strings -Werror -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -c test_printbuf.c
[ 39s] test_printbuf.c: In function 'test_sprintbuf':
[ 39s] test_printbuf.c:127:2: error: format '%d' expects argument of type 'int', but argument 5 has type 'size_t' [-Werror=format]
[ 39s] cc1: all warnings being treated as errors
[ 39s] make[2]: *** [test_printbuf.o] Error 1
[ 39s] make[2]: Leaving directory /home/abuild/rpmbuild/BUILD/json-c-0.10/tests' [ 39s] make[1]: *** [check-am] Error 2 [ 39s] make[1]: Leaving directory/home/abuild/rpmbuild/BUILD/json-c-0.10/tests'
[ 39s] make: *** [check-recursive] Error 1
[ 39s] error: Bad exit status from /var/tmp/rpm-tmp.2aw32L (%check)

Any ideas how to improve the situation ?

Compilation on 64-bit Fedora installation

When I run make, I am given the following output

(CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh ~/Downloads/json-c/missing --run autoheader)
configure.in:44: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
configure.in:44: the top level
rm -f stamp-h1
touch config.h.in
cd . && /bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
make all-recursive
make[1]: Entering directory /home/lucas/Downloads/json-c' Making all in . make[2]: Entering directory/home/lucas/Downloads/json-c'
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT arraylist.lo -MD -MP -MF .deps/arraylist.Tpo -c -o arraylist.lo arraylist.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT arraylist.lo -MD -MP -MF .deps/arraylist.Tpo -c arraylist.c -fPIC -DPIC -o .libs/arraylist.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT arraylist.lo -MD -MP -MF .deps/arraylist.Tpo -c arraylist.c -o arraylist.o >/dev/null 2>&1
mv -f .deps/arraylist.Tpo .deps/arraylist.Plo
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT debug.lo -MD -MP -MF .deps/debug.Tpo -c -o debug.lo debug.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT debug.lo -MD -MP -MF .deps/debug.Tpo -c debug.c -fPIC -DPIC -o .libs/debug.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT debug.lo -MD -MP -MF .deps/debug.Tpo -c debug.c -o debug.o >/dev/null 2>&1
mv -f .deps/debug.Tpo .deps/debug.Plo
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT json_c_version.lo -MD -MP -MF .deps/json_c_version.Tpo -c -o json_c_version.lo json_c_version.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT json_c_version.lo -MD -MP -MF .deps/json_c_version.Tpo -c json_c_version.c -fPIC -DPIC -o .libs/json_c_version.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT json_c_version.lo -MD -MP -MF .deps/json_c_version.Tpo -c json_c_version.c -o json_c_version.o >/dev/null 2>&1
mv -f .deps/json_c_version.Tpo .deps/json_c_version.Plo
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT json_object.lo -MD -MP -MF .deps/json_object.Tpo -c -o json_object.lo json_object.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 -MT json_object.lo -MD -MP -MF .deps/json_object.Tpo -c json_object.c -fPIC -DPIC -o .libs/json_object.o
In file included from json_object.h:16:0,
from linkhash.h:16,
from json_object.c:23:
json_inttypes.h:7:35: error: token "=" is not valid in preprocessor expressions
make[2]: *** [json_object.lo] Error 1
make[2]: Leaving directory /home/lucas/Downloads/json-c' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory/home/lucas/Downloads/json-c'
make: *** [all] Error 2

magic number determines when linkhash.c resizes

Line 128 of linkhash.c is:
if(t->count > t->size * 0.66) lh_table_resize()...

This line means that if the load-factor ( aka count/size ) is larger than 0.66, the table will resize. This is a magic number and it would be awesome if it got moved to a .h file somewhere.

It would also be nice to know the maximum value of this number, which I believe to be 0.99. Thanks!

Failure to build on Raspbian Wheezy

I need to have json-c installed for a particular project (Dantracker - n7nix branch)
I am trying to build it on a Raspberry PI running Raspbian “wheezy”
I followed the instructions as per your wiki ie
(my working directory is /home/pi/dantracker)

$ git clone git://github.com/json-c/json-c.git
$ cd json-c
$ sh autogen.sh
$ ./configure

it then exitst with the comment

configure: creating ./config.status
config.status: error: cannot find input file: `Makefile.in'

Is this due to the Raspbian Wheezy distro, or am i missing something else totally

json_decode strictness - parsing string literals

Hi,
following up on a chain of issuses[1],[2] - there is a parsing strictness issue in json-c where invalid literals are parsed as valid JSON:

234easdasg34

is not a valid JSON [3] but json-c seems to extract the first digits breaking on first invalid character and then returning the parsed part as correct result (this is observed behaviour through PHP inclusion; I haven't built and tested json-c directly yet).

[1] remicollet/pecl-json-c#5
[2] https://bugs.php.net/bug.php?id=65499
[3] http://www.ietf.org/rfc/rfc4627.txt - section 2.1, 2.4

compatibility issue with libjson shim in autoconf

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.