Neels Hofmeyr bd5a1dc84f osmo_fsm_inst_state_chg(): set T also for zero timeout ... Before this patch, if timeout_secs == 0 was passed to osmo_fsm_inst_state_chg(), the previous T value remained set in the osmo_fsm_inst->T. For example: osmo_fsm_inst_state_chg(fi, ST_X, 23, 42); // timer == 23 seconds; fi->T == 42 osmo_fsm_inst_state_chg(fi, ST_Y, 0, 0); // no timer; fi->T == 42! Instead, always set to the T value passed to osmo_fsm_inst_state_chg(). Adjust osmo_fsm_inst_state_chg() API doc; need to rephrase to accurately describe the otherwise unchanged behaviour independently from T. Verify in fsm_test.c. Rationale: it is confusing to have a T number remaining from some past state, especially since the user explicitly passed a T number to osmo_fsm_inst_state_chg(). (Usually we are passing timeout_secs=0, T=0). I first thought this behavior was introduced with osmo_fsm_inst_state_chg_keep_timer(), but in fact osmo_fsm_inst_state_chg() behaved this way from the start. This shows up in the C test for the upcoming tdef API, where the test result printout was showing some past T value sticking around after FSM state transitions. After this patch, there will be no such confusion. Change-Id: I65c7c262674a1bc5f37faeca6aa0320ab0174f3c		2019-01-29 10:25:26 +00:00
..
fsm_test.c	osmo_fsm_inst_state_chg(): set T also for zero timeout	2019-01-29 10:25:26 +00:00
fsm_test.err	osmo_fsm_inst_state_chg(): set T also for zero timeout	2019-01-29 10:25:26 +00:00
fsm_test.ok	osmo_fsm_inst_state_chg(): set T also for zero timeout	2019-01-29 10:25:26 +00:00