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 -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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
participants (2)
-
Harald Welte -
Neels Hofmeyr