diff options
author | Neels Hofmeyr <neels@hofmeyr.de> | 2019-01-28 15:38:09 +0100 |
---|---|---|
committer | Harald Welte <laforge@gnumonks.org> | 2019-01-29 10:25:26 +0000 |
commit | bd5a1dc84f0124d99a89ac187f15c7d34beea210 (patch) | |
tree | 6b932212102ca5fad56a6f2cff3a3deb896cc688 /src/vty/logging_vty.c | |
parent | 4ff41d94ce72afca20f9faaab1ab2f367f1e51aa (diff) |
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
Diffstat (limited to 'src/vty/logging_vty.c')
0 files changed, 0 insertions, 0 deletions