Hi Neels,
in the following commit:
commit 89991fdb7c01fa42e323577b4026985e580763cf Author: Neels Hofmeyr neels@hofmeyr.de Date: Mon Jan 28 19:06:53 2019 +0100
you introduce language about restricting the timeout to a signed 32bit value, as time_t is not well-defined on 32bit systems.
What I'm somehow missing is where we are using time_t in this context? Neither osmo_fsm code nor the underlying osmo_timer_list seems to be using time_t.
So why would we bother about time_t here?
Thanks for sharing your thoughts.
Regards, Harald
On Sat, May 18, 2019 at 01:05:49PM +0200, Harald Welte wrote:
Hi Neels,
in the following commit:
commit 89991fdb7c01fa42e323577b4026985e580763cf Author: Neels Hofmeyr neels@hofmeyr.de Date: Mon Jan 28 19:06:53 2019 +0100
you introduce language about restricting the timeout to a signed 32bit value, as time_t is not well-defined on 32bit systems.
What I'm somehow missing is where we are using time_t in this context? Neither osmo_fsm code nor the underlying osmo_timer_list seems to be using time_t.
I think I was first considering to use time_t, but since that didn't provide a fixed range in a cross-platform way, I chose int32_t instead. IIRC.
~N
-
Harald Welte -
Neels Hofmeyr