Skip child objects and arrays that are not specified in the given object
descriptor when parsing a JSON input string.
This patch adds support for extra child arrays which previously were not
supported by the parser as opposed to additional child objects.
Fixes#47988
Signed-off-by: Markus Fuchs <markus.fuchs@ch.sauter-bc.com>
This patch fixes support for encoding and decoding multidimensional arrays
as described by the JSON_OBJ_DESCR_ARRAY_ARRAY() macro.
Currently, the JSON array encoding and decoding functions, arr_encode()
and arr_parse(), expect array elements to be of object or primitive type.
However, arrays may be nested and so an array's elements may also be
arrays.
In order to support nested arrays, two special cases must be considered:
1. The array of objects/arrays sub-descriptor is described by two
`json_obj_descr` structs and so two instead of one `json_obj_descr`
structs must be skipped when iterating over the JSON descriptor to get to
an array's elements.
2. The implicit array item count field has to be considered for the
parent itself and all its child array items when calculating an element's
size.
Fixes#50801
Signed-off-by: Markus Fuchs <markus.fuchs@ch.sauter-bc.com>
This adds a few line use zephyr_syscall_header() to include
headers containing syscall function prototypes.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Complement the `struct k_mutex` in each fdtable entry
with a `struct k_condvar`. The reasoning for this should be
self-evident.
For a bit of history, `fdtable` was introduced in
commit 06eb489c45 ("kernel: add condition variables")
which predates `struct k_condvar`, introduced in
commit f484bbaa26 ("lib: posix: Implement generic file descriptor table")
by almost 2 years.
Additionally, provide a new accessor function,
`z_get_obj_lock_and_cond()`, that (optionally) gets the mutex
and condition variable associated with the provided object and
vtable.
Signed-off-by: Christopher Friedt <cfriedt@meta.com>
Coverity does not like that we are passing a pointer to a location
just beyond fixed array. Inside the function access is done through
negative indexes so there was no memory corruption but to satisfy
Coverity pointer to the last element of the array is passed and
we start from index 0 instead of -1.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
People interested in those options may be truly concerned by binary
sizes. Let's provide complete information.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
We are currently reporting the wrong mismatching bits in in-between
bundles. Fix this and extend the test to cover the wrong case.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Until now iterable sections APIs have been part of the toolchain
(common) headers. They are not strictly related to a toolchain, they
just rely on linker providing support for sections. Most files relied on
indirect includes to access the API, now, it is included as needed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Analog to json_obj_encode vs. json_calc_encoded_len which
calculates the object len using json_obj_encode, introduce
json_calc_encoded_arr_len which calculates the length using
json_arr_encode. That is needed when the object to be encoded
is array on the root level.
Signed-off-by: Miika Karanki <miika.karanki@vaisala.com>
Remove statement probably left after rebase. ret should be 0 or
error codes, described in docs, and it is rewritten 4 lines below.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
The init infrastructure, found in `init.h`, is currently used by:
- `SYS_INIT`: to call functions before `main`
- `DEVICE_*`: to initialize devices
They are all sorted according to an initialization level + a priority.
`SYS_INIT` calls are really orthogonal to devices, however, the required
function signature requires a `const struct device *dev` as a first
argument. The only reason for that is because the same init machinery is
used by devices, so we have something like:
```c
struct init_entry {
int (*init)(const struct device *dev);
/* only set by DEVICE_*, otherwise NULL */
const struct device *dev;
}
```
As a result, we end up with such weird/ugly pattern:
```c
static int my_init(const struct device *dev)
{
/* always NULL! add ARG_UNUSED to avoid compiler warning */
ARG_UNUSED(dev);
...
}
```
This is really a result of poor internals isolation. This patch proposes
a to make init entries more flexible so that they can accept sytem
initialization calls like this:
```c
static int my_init(void)
{
...
}
```
This is achieved using a union:
```c
union init_function {
/* for SYS_INIT, used when init_entry.dev == NULL */
int (*sys)(void);
/* for DEVICE*, used when init_entry.dev != NULL */
int (*dev)(const struct device *dev);
};
struct init_entry {
/* stores init function (either for SYS_INIT or DEVICE*)
union init_function init_fn;
/* stores device pointer for DEVICE*, NULL for SYS_INIT. Allows
* to know which union entry to call.
*/
const struct device *dev;
}
```
This solution **does not increase ROM usage**, and allows to offer clean
public APIs for both SYS_INIT and DEVICE*. Note that however, init
machinery keeps a coupling with devices.
**NOTE**: This is a breaking change! All `SYS_INIT` functions will need
to be converted to the new signature. See the script offered in the
following commit.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
init: convert SYS_INIT functions to the new signature
Conversion scripted using scripts/utils/migrate_sys_init.py.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
manifest: update projects for SYS_INIT changes
Update modules with updated SYS_INIT calls:
- hal_ti
- lvgl
- sof
- TraceRecorderSource
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: devicetree: devices: adjust test
Adjust test according to the recently introduced SYS_INIT
infrastructure.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: kernel: threads: adjust SYS_INIT call
Adjust to the new signature: int (*init_fn)(void);
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
We get compile warnings of the form:
error: converting the result of
'<<' to a boolean; did you mean
'((__aeabi_ctype_table_ + 1)[(byte)] << 28) != 0'?
[-Werror,-Wint-in-bool-context]
if (!isprint(byte)) {
^
Since isprint (and the other is* functions) return an int, change check
to an explicit test against the return value.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
* Add a flexible Hashmap API
* Add a Separate-Chaining Hashmap Implementation
* Add a Open-Addressing Linear Probe Hashmap Implementation
* Add a C-Wrapper for `std::unordered_map` for benchmarking
Signed-off-by: Chris Friedt <cfriedt@meta.com>
Changed incrementing `for` loop counters to `size_t` from `int` to
eliminate warning, "warning: comparison of integer expressions of
different signedness: 'uint32_t' {aka 'unsigned int'} and 'int'
[-Wsign-compare]"
Signed-off-by: Zachary J. Fields <zachary_fields@yahoo.com>
Changed incrementing `for` loop counters to `size_t` from `int` to
eliminate warning, "warning: comparison of integer expressions of
different signedness: 'uint32_t' {aka 'unsigned int'} and 'int'
[-Wsign-compare]"
Signed-off-by: Zachary J. Fields <zachary_fields@yahoo.com>
Disable tests/kernel/mem_protect/syscalls for qemu_arc_em where
we trigger ARC QEMU bug which cause illegal instruction exception
on perfectly valid ARC code.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
This is a workaround for a compiler bug on (at least) GCC 12.1.0 in
Zephyr SDK 0.15.1. The optimizer generates this function with a last
instruction that is an unconditional branch (a tail call into the
chunk_set() handling). But that means that the NEXT instruction gets
decoded as part of the branch delay slot, but that instruction isn't
part of this function! Some instructions aren't legal in branch delay
slots. One of those is ENTER_S, which is a very common entry
instruction for whatever function the linker places after us. It
seems like the compiler doesn't understand this problem. Stuff a NOP
in to guarantee the code is legal.
Comment above is duplicated in the code. The workaround is
straightforward once the issue is understood, but the path to get here
was hilariously weird.
Fixes#54720
Signed-off-by: Andy Ross <andyross@google.com>
The limiting factor is the output bitmask that says which elements have
been filled in by the parser. This patch changes the bitmask type from int
to int64_t.
Signed-off-by: Björn Stenberg <bjorn@haxx.se>
