If the timer at the head of a ztimer clock's timer list is re-scheduled
(ztimer_set() called on an already set timer) and the timer is no longer
at the head after being re-scheduled, clock-ops->set() is never called
from inside ztimer_set(), and the underlying timer is left with an ISR
scheduled to expire at the timer's old time. The intended behavior is
that the clock's lower level timer should always be set to expire at the
time of the clocks head timer.
This patch changes ztimer_set() to call _ztimer_update(), which sets the
lower level timer according to the current list of timers, rather than
setting the timer directly inside of ztimer_set().
Some calls to `coap_build_hdr()` were done with the target buffer for
the header and the source buffer for the token overlapping:
They reuse the buffer that held the request to assemble the response in.
We cannot use `memcpy()` in this case to copy the token into the target
buffer, as source and destination would (fully) overlap.
This commit makes reusing the request buffer for the response a special
case: `memcpy()` is only used to copy the token if source and
destination address of the token differ.
An alternative fix would have been to use `memmove()` unconditionally.
But `memmove()` does not make any assumption about the layout of target
and source buffer, while we know that the token either will already be
at the right position (when reusing the request buffer for the response)
or be in a non-overlapping buffer (when generating a fresh token). This
approach is more efficient than `memmove()`.
newlib (nano) does not support 64 bit types (neither in stdio nor with
corresponding `PRI*64` macros). With GCC 13.2.1 (as shipped in Ubuntu
24.04.1 LTS), this triggers the following compilation error (even with
`ENABLE_DEBUG == 0`):
sys/matstat/matstat.c:57:21: error: expected ')' before 'PRIu64'
57 | DEBUG("Var: (%" PRIu64 " / (%" PRId32 " - 1)) = %" PRIu64 "\n",
| ^~~~~~
This fixes the issue by falling back to printing 32 bit values when
the `PRIu64` macro is not defined. A `!trunc` is appended when the
64 bit exceeds the range of [0:UINT32_MAX].
The CoAP block option gets written twice:
First a 'dummy' value is written by `coap_opt_add_block2()`, later this gets
overwritten by the real option value by coap_block2_finish().
The problem arises when the size of the option changes.
If the option ends up smaller than the dummy, we have garbage bytes after the
real option value, corrupting the packet.
To mitigate this, always write at least one option byte (which will be a 0 byte)
to ensure the dummy data is overwritten.
fixes#20686
The PSA crypto specification states that when creating keys,
the usage flags PSA_KEY_USAGE_SIGN_HASH/PSA_KEY_USAGE_VERIFY_HASH
automatically set the usage flags
PSA_KEY_USAGE_SIGN_MESSAGE/PSA_KEY_USAGE_VERIFY_MESSAGE on the key.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
When psa_status_t is defined inside crypto_types.h, then all
users of psa_status_t are forced to pull the full range of PSA
Crypto API type definitions.
This however means that psa_status_t cannot be used when defining
those PSA Crypto API types, since doing so would create a cycle.
Fix this by moving the PSA status definitions into a separate header
file which additionally is compatible with the PSA Status code API.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
