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().
* priority_queue_t: Replaced `-1U` literal with PRIORITY_QUEUE_DATA_SIGNALING define
* architecture.h: Added 64-bit
* bloom.h: Fixed typedef for the hashfp_t function pointer
* vfs.h: Increased default vfs buffer sizes for 64 bit
* bytes.h: Check if socklen_t is already defined
* ztimer: Use PRIxPTR format specifier
The sum of an `uint16_t` variable and a literal `1` should still be of
type `uin16_t`. And at least with LLVM 16 this seems to be the case,
but not with the LLVM version in our build container :/
So cast what should have been `uint16_t` anyway explicitly to `uint16_t`
to make that buggy version of LLVM happy.
ztimer's machinery depends on figuring out if a timer is currently set
or not. It does that using _is_set(), which is also exposed as
ztimer_is_set().
Now when a timer expired and got taken of the timer queue using
_now_next(), the `next` pointer wasn't unset. This caused _is_set() to
wrongly return `true` for that timer.
Internally in ztimer, this didn't cause breakage, just an unnecessary
iteration of the timer queue by _delete_timer_from_list().
But this also broke the public ztimer_is_set().
This commit fixes the issue by correctly NULLing the timer's `next`
pointer when the timer triggers.
