Giter Club home page Giter Club logo

json-c's Issues

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.

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!

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

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.

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}]}

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"

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)

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 ?

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

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"

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

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

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

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.

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

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

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...)

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.

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" 

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);
}

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;

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 */

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];
    

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.

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 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?

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

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-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)

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

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.

"./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$

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

`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?

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

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.