This would make it easier to differentiate between released and development versions.

Given the code snippet below:

json_error_t lerror;
json_t *lobject;

std::string strObj = "{"firstName": "John","phoneNumbers": ["212 732-1234", "646 123-4567"]}";
lobject = json_loads(strObj.c_str(), 0, &lerror);

const char *key;
json_t *value;

void *iter = json_object_iter(lobject);
while(iter)
{
key = json_object_iter_key(iter);
value = json_object_iter_value(iter);
std::cout << "key=" << key << "; value=" << value->type << std::endl;

  iter = json_object_iter_next(lobject, iter);
  json_decref(value);

}
json_decref(lobject);

The result (using Jansson 2.0) is:
key=phoneNumbers; value=1
key=firstName; value=2

The correct result is:
key=firstName; value=2
key=phoneNumbers; value=1

The _existing variant would only update keys that already exist and not add new keys at all. The _missing variant would only add new keys and leave the already existing keys alone.

Do we need the byte column in addition to the character column? What about an offset from the stat of input?

json_object_size() returns -1 in failure case, but return type is size_t which is unsigned.

Docs say JANSSON_VERSION_*, the code has JANSSON_*_VERSION. Fix the docs.

With Sphinx v1.02b, the Jansson documentation receives numerous warnings when being compiled. With the sphinx-build -W option in the default build rules, this causes the build to fail. The warning it errors out on:

• default role cfunc not found

For the Fedora packages I had to temporarily remove the -W option from the makefiles to get the package to build on Fedora 14+. I really have no idea what that error even means (Google tells me nothing useful) or what needs to be tweaked in the Jansson files to fix it.

The only tutorial was written for v1.1 and has not been updated since. There are new (and old) features to cover.

There's a starting point for a tutorial using pack/unpack functionality here: http://pastebin.com/YnTMNKv2 (by Jonathan Landis)

It might be nice for json_dumps to let the caller know the length of the string via an out parameter since it should already have it calculated.

If you'd accept this feature I'll happily provide a patch. Currently I'm making unnecessary string copies. Close 2nd would be for you to take an already-malloc'd pointer and use it, rather than always calling strdup.

Currently I'm writing lots of code that looks like this:
if (json_unpack(input, "{so!}", "some_array", &the_array) == -1 ||
!json_is_array(the_array)) {
/* error handling code */
}

I would like to be able to use 'a' in place of the 'o' and not have to check if the returned json_t is an array or not.

The S format character would accept a string or NULL.

See https://groups.google.com/d/msg/jansson-users/YLLDHM9-ZL4/_imoWCROXXoJ for an initial patch by Ladar Levison.

I cloned the latest and tried to build and run the tests on Fedora 15,
which has gcc-4.6. Here's the failure I saw:

test_load.c: In function 'main':
test_load.c:14:13: error: variable 'json' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
make[4]: *** [test_load.o] Error 1
make[4]: *** Waiting for unfinished jobs....

Here's one way to avoid the warning while improving that test at the
same time:
From 7443fb976063c48315ec65e1e1cc8bb7bf72b159 Mon Sep 17 00:00:00 2001
From: Jim Meyering [email protected]
Date: Tue, 5 Apr 2011 14:04:16 +0200
Subject: [PATCH] avoid set-but-not-used warning/error in a test

---
 test/suites/api/test_load.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/test/suites/api/test_load.c b/test/suites/api/test_load.c
index b1679a3..ecb46d8 100644
--- a/test/suites/api/test_load.c
+++ b/test/suites/api/test_load.c
@@ -15,6 +15,8 @@ int main()
     json_error_t error;

     json = json_load_file("/path/to/nonexistent/file.json", 0, &error);
+    if(json)
+        fail("json_load_file returned non-NULL for a nonexistent file");
     if(error.line != -1)
         fail("json_load_file returned an invalid line number");
     if(strcmp(error.text, "unable to open /path/to/nonexistent/file.json: No such file or directory") != 0)
--
1.7.5.rc0.351.gebf36

This would require at least two new API functions: for creating a string value from buffer and length, and for querying the length of a string value. For example:

json_t *json_string_from_buffer(const char *buffer, size_t length);
json_t *json_string_from_buffer_nocheck(const char *buffer, size_t length);
size_t json_string_length(json_t *json);

The length of strings would have to be stored internally and never use strlen(). The internals would also always have to prepare to handle strings with embedded null bytes.

It would be nice for the unpack api to have an ability to check if the JSON object has entries that were not unpacked. E.g. I'm planning to have my config files in JSON format, and unpack seems easiest way to populate it to internal structs; but it would be nice to print a warning for unrecognized entries.

This could be by having a function variant with explicit callback for unrecognized entries; or perhaps have per-each object a "num_parsed" field that could be compared against the hash table size to see if there's unhandled entries (and each hashtable pair would then need a flag if it was parsed or not).

Empasize that the return value of json_string_value() is managed by Jansson

object_key_compare_serials() should do a real comparison instead of subtraction.

This is useful when parsing from a string with JSON_DISABLE_EOF_CHECK. The position member of the error struct can be used.

Hi Petri =))

CMake building system going to be more popular. It will be good to add this build system support.

I wrote working example code for this project, which should be place in "src" directory into file CMakeLists.txt

include_directories(${CMAKE_CURRENT_SOURCE_DIR})

set(janson_SOURCES
dump.c
error.c
hashtable.c
hashtable.h
jansson_private.h
load.c
memory.c
pack_unpack.c
strbuffer.c
strbuffer.h
utf.c
utf.h
value.c)

add_library(janson STATIC ${janson_SOURCES})

This code builds jansson as a static libary.

ru_RU.utf8:

make check-TESTS
make[3]: Вход в каталог `/home/nakulov/sources/jansson-2.3/test'
Suite: api
......F......
=================================================================
api/test_load.c
=================================================================
test_load.c:file_not_found:23: json_load_file returned an invalid
error message

=================================================================
Suite: invalid
...............................................
Suite: invalid-unicode
..................
Suite: valid
.................................
1 of 4 test suites failed
FAIL: run-suites
================================
1 of 1 test failed
Please report to [email protected]
================================
make[3]: *** [check-TESTS] Ошибка 1
make[3]: Выход из каталога `/home/nakulov/sources/jansson-2.3/test'
make[2]: *** [check-am] Ошибка 2
make[2]: Выход из каталога `/home/nakulov/sources/jansson-2.3/test'
make[1]: *** [check-recursive] Ошибка 1
make[1]: Выход из каталога `/home/nakulov/sources/jansson-2.3/test'
make: *** [check-recursive] Ошибка 1

It's like the internal do_dump() interface, allowing the user to provide a callback that's called for each (variable length) chunk of output.

See https://groups.google.com/d/topic/jansson-users/b5-KA0TM3eA/discussion for the suggestion by Basile Starynkevich

The new features that were introduced after Graeme's initial patch are totally untested.

All numbers or only overflowing numbers, or maybe two separate flags?

There's good test data at https://github.com/stig/json-framework/issues#issue/43

The v2 API will be shut down on May 1st 2012.

Add a decoding flag that makes decoder stop after decoding a valid JSON array or object. This would make it possible to e.g. store many JSON values inside a file, or store JSON and other data, and still be able to decode it with Jansson.

I would like to be able to take different actions depending on the type of error I get from lson_loads().
Currently I detect incompletely received JSON data by checking error.position == received_len, but I would like to be able to do more than that.
For example it would be nice to be able to distinguish errors caused by the EOF check from errors triggered by JSON_REJECT_DUPLICATES from bad JSON.

Document the lifecycle of the string produced by the 's' format to json_unpack().

Implement an incremental/restartable parser that doesn’t require all the input available when the parsing begins, i.e. the user could feed the parser with input data as soon as it is available. This requires some major refactoring to the parser, the lexer and the UTF-8 input layer.

Unsupported encodings (UTF-16, UTF-32) should be detected and a proper error message generated for them. BOMs should also be supported and the UTF-8 BOM ignored.

Use a flag to json_load*() functions to trigger this behavior.

The serial value should be reset to zero in json_object_clear().

Hey there. If a mega-large integer is encountered in the json data, I get a 'too big integer near ...' error. Can we check to see if the integer is > maxint, and then store it as a string or something instead of failing to parse the json data?

I'm trying to parse the twitter stream using the lib and it's choking on this json string part:
... ,"id_str":"6572981622935552", ...

• Steve Webb

While parsing correct JSON string, it fails with this error on double values. Debugger shows that double value was successfully returned by strtod() function, but next if (errno == ERANGE) comparison fails.

The problem is probably that errno value should be set to zero before calling strtod() function, which doesn't change it in the successful case. See line 531 in load.c

The problem is probably the functions that honor the LC_CTYPE category (isupper(), islower(), etc.). The failures can be reproduced by running the test suite under the ca_FR.ISO-8859-1 locale, for example.

See title, my simple patch here: https://github.com/revmischa/jansson/commit/2ce7dcd2e01763dc43ddc10d8c8dfa0c79e8575c

json_load*() functions now have the extra flags parameter, so this is just a matter of adding a flag.

Hello @akheron,

First of all, I would like to thank you for taking the time to develop this library. It's incredibly well written and of immense value to a project I'm currently working on. The API is really consistent and pretty sane.

I would like to propose the addition of a new macro to the main header: json_object_foreach, with the purpose of reducing the amount of code required to iterate over an object. The macro definition would be something along the lines of:

#define json_object_foreach(k, v, x) \
    const char *k; \
    json_t *v; \
    for(void *__json_iterator__ = json_object_iter(x); \
        __json_iterator__ && \
        (k = json_object_iter_key(__json_iterator__), v = json_object_iter_value(__json_iterator__), 1); \
        __json_iterator__ = json_object_iter_next(x, __json_iterator__))

That allows the simplification of iteration code from:

const char *key;
json_t *value;
void *iter = json_object_iter(obj);
while(iter)
{
    key = json_object_iter_key(iter);
    value = json_object_iter_value(iter);
    /* use key and value ... */
    iter = json_object_iter_next(obj, iter);
}

To:

json_object_foreach(key, value, object) 
{
    /* use key and value ... */
}

I could not think of any drawbacks (performance of otherwise) of using this. If you like the idea, I can fork the repo and issue a pull request with the code.

Thanks.

Supposedly, "int json_unpack(json_t *root, const char *fmt, ...)" should accept 'const json_t *root' instead since it doesn't change the state of the object.

With locales other than C or POSIX, the decimal separator may be something else than '.'. In this case, the encoders produces invalid JSON when it encodes real numbers.

This is just a matter of adding an encoding flag. The default (without any flags) should still be to only encode objects and arrays.

Please find below 2 errors detected by static analyzer:

Pointer 'json_string_value(string1)' returned from call to function 'json_string_value' at line 730 may be NULL and will be dereferenced at line 730. : D:\temp\jansson-2.0.1.tar\jansson-2.0.1\jansson-2.0.1\src\value.c : 730 : Error : Analyze

Pointer 'json_string_value(string2)' returned from call to function 'json_string_value' at line 730 may be NULL and will be dereferenced at line 730. : D:\temp\jansson-2.0.1.tar\jansson-2.0.1\jansson-2.0.1\src\value.c : 730 : Error : Analyze

The encoder tracks reference loops by mutating the visited value of objects and arrays. If two encoders run in parallel for a single object or array, this fails hard.

Running Sphinx v1.0.7
loading pickled environment... not yet created
building [html]: targets for 6 source files that are out of date
updating environment: 6 added, 0 changed, 0 removed
reading sources... [100%] tutorial
jansson-2.0/doc/index.rst:32: (WARNING/2) toctree contains reference to nonexisting document u'upgrading'

Even though long long is available on MinGW, %lld doesn't work and %I64d should be used instead. See http://cboard.cprogramming.com/cplusplus-programming/118149-long-long-int-gplusplus-mingw.html and http://old.nabble.com/long-long-vs-__int64-td28460840.html#a28460840.

An extra zero is (sometimes?) preceded to the exponent of real numbers. Also, everything in the invalid-unicode suite fails even though the expected and actual outputs look similar.

Add a ./configure option --with-ascii-only or such that would switch the library to an ASCII only mode. In this mode, only 7-bit ASCII would be accepted and all UTF-8 related code would be replaced with (probably smaller and more efficient) code that only handles ASCII.

One possible use case would be low-specification systems with very limited CPU or RAM.

Add portability info, change title

It would nice from performance point of view to be able to generate JSON stream directly from pack api calls. It would allow me to easily create on-wire representation from my struct.