Quote:
Originally Posted by
RudiC
To be on the safe side, you might want to AND the STATE operand with 0xF8 as well, and check that in STATE only one bit is set...
Agreed. I'm just not sure that we have a true specification of what this macro is supposed to do yet. I've worked on a lot of finite state machines, but the state changes described for this project still seem unusual to me. There seems to be a state0, but instead of having a bit identifying state0; it is identified by being not in state1, state2, or state3.
I was expecting to hear that my suggested change is a step in the right direction, but still isn't doing some things right. Should
INA_SAVE_APP_STATE(state4) really clear
state1,
state2, and
state3 from
appState? Shouldn't there be some way to clear
state4 through
state8? Shouldn't there be a macro to initialize the state? (Maybe the header always defines appState to be an extern int (or char); but we haven't seen any evidence of that yet, and these macros won't behave as desired if appState is an uninitialized variable allocated on the stack.) There is no defined error mechanism. (What should happen if one calls
INA_SAVE_APP_STATE(state1 | state2)?) Et cetera.
I'm still hoping for an actual set of specifications of the allowed state transitions, what happens when an illegal state is passed in, etc.