One hot encoding of the states of a C FSM - c

Question

Basically, I just would like to know if this is a good idea to manually one hot encode the states of a C FSM.
I implemented that to write an easy state transition validator:
typedef enum
{
FSM_State1 = (1 << 0),
FSM_State2 = (1 << 1),
FSM_State3 = (1 << 2),
FSM_StateError = (1 << 3)
} states_t;
Then the validation:
states_t nextState, requestedState;
uint32_t validDestStates = 0;
// Compute requested state
requestedState = FSM_State1;
// Define valid transitions
validDestStates |= FSM_State2;
validDestStates |= FSM_State3;
// Check transition
if (validDestStates & requestedState)
{
// Valid transition
nextState = requestedState;
}
else
{
// Illegal transition
nextState = FSM_StateError;
}
I know that I am limited to the maximum size of integer that I can use. But I don't have that many states. So it is not an issue
Is there something better than this encoding?
Are there some drawbacks I don't see yet?
Thanks for your help!
Edit: changed validation test according to user3386109 comment
Final thoughts
So final here is what I did:
1/ State enum is a "classical" enum:
typedef enum
{
FSM_State1,
FSM_State2,
FSM_State3,
FSM_StateError
} states_t;
2/ Bit fields for valid transitions:
struct s_fsm_stateValidation
{
bool State1IsValid: 1;
bool State2Valid: 1;
bool State3IsValid: 1;
bool StateErrorIsValid: 1;
/// Reserved space for 32bit reserved in the union
uint32_t reserved: 28;
};
3/ Create an union for the validation
typedef union FSM_stateValidation_u
{
/// The bit field of critical system errors
struct s_fsm_stateValidation state;
/// Access the bit field as a whole
uint32_t all;
} u_FSM_stateValidation;
4/ I changed the validation:
u_FSM_stateValidation validDestStates;
// Set valid states
validDestStates.state.State1 = true;
// Compute requestedState
requestedState = FSM_State2;
if ((validDestStates.all & ((uint32_t) (1 << requestedState)) ))
{
// Next state is legal
return requestedState;
}
else
{
return FSM_StateError;
}

Answer 1

From a quick Google, "one hot encoded" means that every valid code has precisely one bit set, which seems to be what you're doing. The search results suggested this was a hardware design pattern.
Drawbacks I can think of are...
As you suggest, you're dramatically limiting the number of valid codes - for 32 bits you have a maximum of 32 codes/states instead of more than 4 billion.
It's not ideal for lookup tables, which are a common implementation for switch statements. There are usually an intrinsic available to determine which is the lowest bit set, but I wouldn't bet on compilers using that automatically.
Those aren't big issues, though, provided the number of states is small.
The question IMO, then, is whether there's an advantage to justify that cost. It doesn't need to be a huge advantage, but there has to be some kind of point.
The best I can come up with is that you can use bitwise tricks to specify sets of states, so you can test whether the current state is in a given set efficiently - if you have some action that needs to be done in states (1<<0) and (1<<3), for example, you could test if (state & 0x9).