Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>

Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>

This reverts commit aaba8c1080.

This commit breaks builddir != srcdir build, but, more importantly, it
also adds a dependency on a header, "config.h", which is not installed
and it's supposed to be private — since it's generated at configuration
time and it's not meant to be used by projects compiling against a
library.

Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>

Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>

Fix issues with the test script so it works under distcheck too.

The last json_tokener_errors change affects the binary package, we need a bump to solve the issue.

See [this bug of postgis.](https://bugzilla.redhat.com/show_bug.cgi?id=1123785)

* CVE-2013-6371: hash collision denial of service
* CVE-2013-6370: buffer overflow if size_t is larger than int

Conflicts:
	Makefile.am

The -Bsymbolic-functions linker flag reduces the amount of PLT jumps in
a shared object, and has a side effect of preventing symbol collisions
in libraries and applications linking against two different shared
objects exposing the same symbol.

While the former is (generally) a performance win, the latter is less
rare than expected. For instance, PulseAudio started linking against
json-c a while ago; now, every project linking against PulseAudio is
leaking json-c symbols. In the GNOME platform, this means that projects
linking against PulseAudio cannot be safely linked against other
libraries depending on the GLib-based JSON parsing libraries JSON-GLib,
because of a symbol conflict. Nominally, this conflict would not be an
issue: libraries and applications do not need to depend on two different
JSON parsing libraries; the symbol leakage, though, ends up causing
either segmentation faults, or weird errors. For further reference,
please see: https://bugzilla.gnome.org/show_bug.cgi?id=703734

JSON-GLib already switched to using -Bsymbolic-functions, but it would
be safe if json-c did the same, wherever the linker flag is available.

I think this should work, but I can't test it.

Also rename the json-c-uninstalled.pc file.

Conflicts:
	.gitignore
	Makefile.am
	configure.in
	printbuf.c
	test1.c
	test1.expected

Android build system

This dependson the Androgenizer project, which helps keep autofoo-based build
systems in sync with the Android build.

Changing root name of library to json-c, and also the
directory where header files are installed to .../jsdon-c/*.

This avoids clashes with other implementations of JSON libraries.

As part of this create a public json_config.h with a custom define to
decide whether to include inttypes.h to avoid conflicting with other
projects config.h header.

This allows building DLLs for windows - libtool doesn't even
try to do that unless this flag is specified.

git-svn-id: http://svn.metaparadigm.com/svn/json-c/trunk@70 327403b1-1117-474d-bef2-5cb71233fd97

git-svn-id: http://svn.metaparadigm.com/svn/json-c/trunk@68 327403b1-1117-474d-bef2-5cb71233fd97

Added parse_null test. This does not change anything with how the parser handles \u0000 or null characters

This commit is addapted from one by Adomas Paltanavičius <adomas@leanholding.com>



git-svn-id: http://svn.metaparadigm.com/svn/json-c/trunk@63 327403b1-1117-474d-bef2-5cb71233fd97

json_object_get_int64. Binary compatibility preserved.
    Eric Haszlakiewicz, EHASZLA at transunion com
    Rui Miguel Silva Seabra, rms at 1407 dot org



git-svn-id: http://svn.metaparadigm.com/svn/json-c/trunk@56 327403b1-1117-474d-bef2-5cb71233fd97

git-svn-id: http://svn.metaparadigm.com/svn/json-c/trunk@53 327403b1-1117-474d-bef2-5cb71233fd97

git-svn-id: http://svn.metaparadigm.com/svn/json-c/trunk@51 327403b1-1117-474d-bef2-5cb71233fd97