In case of hdb.c, the problem is that `check` public API (qb_hdb_handle
member struct) item (which should not be exposed publicly like this
in the first place!) is typed as `int32_t`, whereas it was to be
compared to `uint32_t` implementation-possessed local variables
(presumably derived from the same source), which made the compiler
upset (even though there was no real reason, integer promotion to
unsigned type would happily occur, which is furthermore expected to
be fully defined as these values come from `random` that shall
return non-negative integers below `INT32_MAX`).
Hence:
- type these local variables to `int32_t` just as well, which allows to
- simplify `random` return value handling, since they are expected to be
zero-or-greater and the previously extra tested all-bits-on pattern
makes undoubtfully for a negative numeric value in case of a signed
integer with specified width (c.f. 7.18.1.1/C99), hence falling into
complement of zero-or-greater; zero itself is also excluded for the
reasons stated in the comment (which was pretty hazy and incorrect,
so it gets overhaul as well)
- also superfluous typecasts are removed
Similar situation is with loop_timerlist.c, where we are actually fully
in charge of the struct member (private API), but there are good reasons
to stay consistent with the former file as the same applies to the
source of that value -- it comes from `random` (equivalent comment
is added here for greater symmetry).
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
timefd is using too much cpu and it is using up
file descriptors.
timelist is also more portable and now I have less
code to maintain.
Signed-off-by: Angus Salkeld <asalkeld@redhat.com>
This changes the timer hande from a live pointer to a handle
more like hdb handles (minus the ref counting).
What i like about this is it is not neccessary to clear
the applications handle using memset().
Signed-off-by: Angus Salkeld <asalkeld@redhat.com>
