Users of the "o" format have an expectation that the object reference
will be stolen. Any error causes the collection process to end early.
This patch causes json_pack and related functions to continue scanning
the format and parameters so all references can be stolen to prevent
leaks. This makes no attempt to continue processing if the format
string is broken or missing.
'make check' still passes. Ran test_pack under valgrind and verified
that the leaked reference is fixed. Added a test which uses refcounts
to verify that the reference was correctly stolen after a NULL value
error.
Issue #135
Make parse_object use json_object_set_new_nocheck and make parse_array
use json_array_append_new, remove json_decref from error and success
paths.
Fixes#376
The JSON_EMBED encoding flag causes the opening and closing characters
of the top-level array ('[', ']') or object ('{', '}') to be omitted
during encoding. This feature makes it possible to concatenate multiple
arrays or objects in the stream output. It also makes it possible to
perform outputs of partial composes.
One such example of a partial compose is when outputting a JWE object.
The output is a JSON object. But it has one top-level attribute
("ciphertext") that can grow out of proportion with the rest of the
metadata. With the JSON_EMBED flag, the other metadata can be composed
ahead of time and dumped during the beginning of output, where the
"ciphertext" and "tag" attributes can be streamed out in chunks. Thus,
the header material can be composed with Jansson and the ciphertext
itself can be composed manually.
This function encodes the json_t object to a pre-allocated buffer.
It compliments the already existing json_loadb() function and is
useful for parsing JSON-RPC (among other protocols) when sent over
datagram sockets.
Signed-off-by: Nathaniel McCallum <npmccallum@redhat.com>
The fix limits recursion depths when parsing arrays and objects.
The limit is configurable via the `JSON_PARSER_MAX_DEPTH` setting
within `jansson_config.h` and is set by default to 2048.
Update the RFC conformance document to note the limit; the RFC
allows limits to be set by the implementation so nothing has
actually changed w.r.t. conformance state.
Reported by Gustavo Grieco.
Otherwise figuring out what's wrong with your JSON can be tricky,
especially if you're using a single fmt string to validate a large,
complicated schema.
The comma delimiting will make separating keys that contain commas
difficult. For example:
{"foo, bar": true, "baz": false}
will generate errors like:
2 object item(s) left unpacked: foo, bar, baz
but that seems like a small enough corner case to not be worth much
worrying.
I wanted to find a way to handle this without have_unrecognized_keys,
but the strbuffer tooling makes it look like I shouldn't be reaching
in to do things like:
strbuffer_t unrecognized_keys;
unrecognized_keys.value = NULL;
and then using 'unrecognized_keys.value == NULL' in place of
have_unrecognized_keys.
This is particularly useful in modular situations where the allocation
functions are either unknown or private. For instance, in such cases,
the caller of json_dumps() has no way to free the returned buffer.
This is both good practice and nice for OpenBSD users, who will no
longer get the nag message to not use sprintf/strcpy every time they
link against jansson. It's worth noting that the existing code seems
safe to me - bounds checks were already happening before the actual
calls - and that this is for extra security.
This has the consequence that numbers are never converted to integers
when JSON_DECODE_INT_AS_REAL is set, and thus it works correctly all
integers that are representable as double.
Fixes#212.
The previous commit introduced a loop on all input keys to check the
strict mode. We can avoid this if we don't expect an optional key. In
this case, we fallback to the previous method to compare the length of
the set of expected keys and the length of the parsed keys.
On unpack, one may want to mix `JSON_STRICT` and optional keys by using
a format like `{s:i,s?o!}`. Unfortunately, this fails the stric test
with `-1 object item(s) left unpacked` error when the second key is not
specified.
To fix that, we iter on each key and we check if we have successfully
unpacked them. This is less efficient than the previous method but it
brings correctness.
First, wrap "advapi32.dll" into the TEXT() macro. If UNICODE is defined,
GetModuleHandle() redirects to GetModuleHandleW(), which excepts a wchar_t*
UTF-16 parameter, thus causing a compile error. TEXT() prefixes the string
literal with L in this case, and does nothing otherwise.
Second, make sure that CryptGenRandom() is actually called through the function
pointer retrieved by the call to GetProcAddress() above.
And third, replace _getpid() with the equivalent and more ubiquitous Win32 API
function GetCurrentProcessId(). Since _getpid() is not exported by all C
runtimes on Windows (most notably the Driver Development Kit), using it might
introduce previously unneeded runtime dependencies. GetCurrentProcessId(), on
the other hand, has been available in kernel32.dll since at least Windows 95,
just like the other API functions used in this code (GetModuleHandle() and
GetProcAddress()).
This is because it's really easy to get a name collission if compiling
Jansson as a subproject in a larger CMake project. If one project includes
several subprojects each having their own config.h, this will cause the
wrong file to be loaded.
Since len is known, the copy function does not need to check byte by byte
the end of the string.
Signed-off-by: Olivier Langlois <olivier@olivierlanglois.net>
When building a "MinSizeRel" with CMake I get a compilation error in lex_unget_unsave. This is because assertions are turned off using -DNDEBUG:
```
/usr/bin/gcc -DHAVE_CONFIG_H -fPIC -Os -DNDEBUG -Ijansson/build/include -Ijansson/build/private_include -Wall -Wextra -Wdeclaration-after-statement -Werror -o CMakeFiles/jansson.dir/src/load.c.o -c jansson/src/load.c
jansson/src/load.c: In function âx_unget_unsaveâjansson/src/load.c:256:14: error: variable â set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
```
This will then remove the insert, which makes the "d" variable unused, which is treated as an error since we have -Wall set. We can't simply get rid of the variable either and put the strbuffer_pop call in the assert call, since it's a macro and would remove the call entirely. So I simply added a check for NDEBUG to fix it.
