Support parsing and serializing of struct fields that are defined as a
char array.
Use the token JSON_TOK_STRING_BUF to parse and serialize a string for a
char array, for example:
struct foo {
const char *str;
char str_buf[30];
};
struct json_obj_descr foo_descr[] = {
JSON_OBJ_DESCR_PRIM(struct foo, str, JSON_TOK_STRING),
JSON_OBJ_DESCR_PRIM(struct foo, str_buf, JSON_TOK_STRING_BUF),
};
The struct 'json_obj_descr' now has an additional union member 'field'
to store the size of the struct field, which is used with the token
'JSON_TOK_STRING_BUF' to determine the element size.
Fixes: #65200
Signed-off-by: Christoph Winklhofer <cj.winklhofer@gmail.com>
Up to now, the handling of type float was offloaded to the users of the
JSON utility, with the token JSON_TOK_FLOAT.
Improve handling of floating point types and support the types 'float'
and 'double' in a built-in way so that they can be directly parsed to
and serialized from variables (of type float or double).
The types are serialized in the shortest representation, either as a
decimal number or in scientific notation:
* float (with JSON_TOK_FLOAT_FP): encoded with maximal 9 digits
* double (with JSON_TOK_DOUBLE_FP): encoded with maximal 16 digits
* NaN, Infinity, -Infinity: encoded and decoded as:
{"nan_val":NaN,"inf_pos":Infinity,"inf_neg":-Infinity}
Enable the floating point functionality with the Kconfig option:
JSON_LIBRARY_FP_SUPPORT=y
It requires a libc implementation with support for floating point
functions: strtof(), strtod(), isnan() and isinf().
Fixes: #59412
Signed-off-by: Christoph Winklhofer <cj.winklhofer@gmail.com>
Add support to decode the special floating point values NaN, Infinity
and -Infinity. For example:
{"nan_val":NaN,"inf_pos":Infinity,"inf_neg":-Infinity}
Note that this commit is a preparation for the built-in support of
floating point values and these are only accepted when compiled with
the flag -DCONFIG_JSON_LIBRARY_FP_SUPPORT.
Signed-off-by: Christoph Winklhofer <cj.winklhofer@gmail.com>
Add support to decode floating point numbers in scientific notation,
e.g. 3.40282347e+38. Only the lower-case specifier 'e' is allowed.
Signed-off-by: Christoph Winklhofer <cj.winklhofer@gmail.com>
The calculation of the object size may be incorrect when the size of
a field is smaller than the struct alignment. When such a struct is
used in an array field, the decoded object contains wrong values.
The alignment influences the object size. For example the following
struct has a calculated object size of 8 bytes, however due to
alignment the real size of the struct is 12 bytes:
struct test_bool {
bool b1; /* offset 0, size 1 */
/* 3-byte padding */
int i1; /* offset 4, size 4 */
bool b2; /* offset 8, size 1 */
/* 3-byte padding */
};
This commit changes the object size calculation and computes the size
with the offset and size of the last field in the struct (rounded up
by the struct alignment).
Fixes: #85121
Signed-off-by: Christoph Winklhofer <cj.winklhofer@gmail.com>
Utilize a code spell-checking tool to scan for and correct spelling errors
in various files within the `lib` directory.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
Introduce support for 'uint64_t' type, so that unsigned numbers
can be serialized into JSON payloads.
Signed-off-by: Mykhailo Lohvynenko <Mykhailo_Lohvynenko@epam.com>
Up to now there was only support for parsing/encoding 32-bit integer
numbers, with no support for larger ones.
Introduce support for 'int64_t' type, so that large numbers can be
serialized into JSON payloads.
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
Currently, json array macros are passing the outer "container" struct
to the Z_JSON_ELEMENT_DESCR macro, causing the alignment to be calculated
from the outer struct which may be incorrect. Fix this by using the
biggest shift from the nested objects to calculate the alignment as the
struct size is calculated based on the biggest alignment of it's members.
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Move various utilities out of lib into own folder for better assignement
and management in the maintainer file. lib/os has become another dumping
ground for everything and it the Kconfig and contents in that folder
became difficult to manage, configure and test.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
