This was causing an unaligned pointer read on some architectures,
leading to crashes. This could be alternatively solved by rounding
the size to the nearest power of 2, but this wouldn't work with
packed structs.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
This appears to be a bug in GCC: when an anonymous union contains
anonymous structs, GCC issues a warning that a field in one of the
anonymous structs has not been initialized. Fix by making the
structs not anonymous.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
append_bytes_to_buf() already writes a NUL byte; no need to call
append_bytes() again with "" and size 1.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Since JSON_OBJ_DESCR_ARRAY is suitable only for arrays of primitives,
add JSON_OBJ_DESCR_OBJ_ARRAY (and a ..._NAMED variant), to allow users
to handle arrays of objects.
Having a macro is important, given the unintuitive space optimization
used for storing the offset to the structure element containing the
number of elements in the array.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
This function currently fails when decoding an array with number of
elements exactly equal to the maximum available in the struct.
To fix this, move the check for if the current field is past the end
of the array to just before attempting to decode a value. This allows
the last element to be followed by a JSON_TOK_LIST_END token in the
case that the array is full, and the function to return success.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
The JSON library doesn't properly encode arrays whose elements are of
object type. Fix that.
This fix avoids allocating a temporary descriptor on the stack, and
keeps the size of struct json_obj_descr unchanged, by preserving an
unintuitive size optimization made by the library. See the comments
in the patch for more details.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
This (and JSON_OBJ_DESCR_ARRAY_NAMED) are really intended for handling
arrays of primitive type only. They don't allow users to declare
descriptors for arrays of objects. Clarify this in the Doxygen.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Move all characters to "char" type: no implicit conversions between
"unsigned char", "u8_t", etc.
Tested with ISSM 2016.2.085.
Jira: ZEP-2159
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
The set of valid JSON field names is larger than the set of C
identifiers. This can result in structure field names which pack
decoded JSON values which necessarily differ from the field names in
the JSON.
Support this by adding _NAMED variants to each of the JSON_OBJ_DESCR_*
helper macros. For example, JSON_OBJ_DESCR_PRIM_NAMED allows users to
declare a descriptor field for a primitive type, whose structure field
name is different from the JSON field name.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Currently, json_escape() allocates a temporary buffer on the stack
that's the size of the string being escaped.
Stack space is precious and longer JSON strings can run into the
hundreds of bytes, so re-implement this routine to escape in place.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
There are already helper macros for declaring descriptor fields of
object and array type. Add one for primitive types as well.
The fact that the JSON test code defines one proves that it's useful,
so there should be one provided for other users.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Convert code to use u{8,16,32,64}_t and s{8,16,32,64}_t instead of C99
integer types.
Jira: ZEP-2051
Change-Id: I74bc6384c4090f4ae322e3aa151874f583a5fe73
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
This is a start to move away from the C99 {u}int{8,16,32,64}_t types to
Zephyr defined u{8,16,32,64}_t and s{8,16,32,64}_t. This allows Zephyr
to define the sized types in a consistent manor across all the
architectures we support and not conflict with what various compilers
and libc might do with regards to the C99 types.
We introduce <zephyr/types.h> as part of this and have it include
<stdint.h> for now until we transition all the code away from the C99
types.
We go with u{8,16,32,64}_t and s{8,16,32,64}_t as there are some
existing variables defined u8 & u16 as well as to be consistent with
Zephyr naming conventions.
Jira: ZEP-2051
Change-Id: I451fed0623b029d65866622e478225dfab2c0ca8
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
If we use newlib the isdigit (and other similar functions) return an
error as char can possibly be viewed as signed:
usr/include/ctype.h:57:54: error: array subscript has type ‘char’ [-Werror=char-subscripts]
#define __ctype_lookup(__c) ((__ctype_ptr__+sizeof(""[__c]))[(int)(__c)])
Being explicit about the char being unsigned char deals with this.
Change-Id: If2416218220ef5b29f1a69470cbcc6b4fd49ef86
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Boolean values were being decoded using the descriptor type rather than
the value type.
Jira: ZEP-1607
Change-Id: I0c9324ee705af973ccf738e92785820c3a5fb692
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
The function to ignore spaces was not being called, so some tokens had
whitespace in the beginning. They were correctly lexed, but parsing
could eventually fail.
Jira: ZEP-1607
Change-Id: I796596143895fa0fa652641f56af9a03e7a65b7a
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Comparing *endptr with '\0' will always be true before replacing
*token->end with prev_end.
Jira: ZEP-1607
Change-Id: I224129586e15380d3919bfba3db4fcf38c28cb07
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
It has been suggested in a review to use a simple function with a
switch statement instead of the table trick.
Jira: ZEP-1607
Change-Id: I5290de175021bfa8642334548ece8266d4c137f0
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Roll the loop in an accept_run() function and use it to match "rue" and
"alse" depending on the first character of the token. Use that to lex
"ull" after finding "n" as well. This reduces the code slightly.
Jira: ZEP-1607
Change-Id: Iec8ff6ae2fb79e7fe65d476d1574c5943d23e14f
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Serializing an object in JSON is quite tricky to do by hand, and with
an array of descriptor structs, there's enough information to do that
programatically.
The encoder takes a callback function, so that one can be written to
write bytes to, for instance, a struct net_buf. This way, there's no
guesswork to determine the buffer size, reducing the possibility of
overflowing the stack.
Jira: ZEP-1607
Change-Id: I5ccf1012e46c1db32fcfdf2ecee4a1ef44c927d5
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Parse arrays and nested objects.
Array parsing is limited to items of the same type, and requires an array
with fixed number of elements. Elements can be of any type supported by
the parser, including arrays and objects.
The return value of json_obj_parse() won't be that helpful: the nth bit
will only be set if the object has been fully decoded.
Jira: ZEP-1607
Change-Id: I472e402ae3f36a1bd1505decc0313f74cbfa2e07
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
This is a minimal JSON parser (and string encoder helper). This has
been originally written for the NATS client sample project, but since
it's a generic bit of code, it's also being provided as a library
outside the NATS application source.
It's limited (no support for arrays, nested objects, only integer
numbers, etc), but it is sufficient for the NATS protocol to work.
Jira: ZEP-1012
Change-Id: Ibfe64aa1884e8763576ec5862f77e81b4fd54b69
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Anas Nashif