Why do I need this strange cast for enum arithmetics? - c

Question

I have this piece of code:
typedef enum myEnum_e
{
VAL0,
VAL1
} myEnum;
void func(void)
{
myEnum val = (myEnum) 0;
while(/*Do something*/)
{
val = val + ((myEnum)1); // <= Warning here
}
}
This piece of code produces the warning:
enumerated type mixed with another type
To clean this I ended up with:
void func(void)
{
myEnum val = (myEnum) 0;
while(/*Do something*/)
{
val = ((myEnum) val + 1); // <= NO Warning here
}
}
Could someone tell why the first form is incorrect?
I feel like the second is less meaningful than the first one.
I mean I would prefer to read:
Add 1, considered as a myEnum value, to val (and store the result in val)
Than
Store in val val + 1 considered as a myEnum value
Note: This is a TI C28x compiler (for TI C2000 MCUs).
Edit:
My real application is to define a custom UART communication for embedded software.
So here is what I have done:
typedef enum e_frame
{
FRAME_A,
FRAME_B,
FRAME_C,
FRAME_COUNT
} frame_e;
typedef enum e_frameId
{
FRAMEID_A = 0x0A,
FRAMEID_B = 0x42,
FRAMEID_C = 0xFF
} frameId_e;
const frameInfo_s FramesInfo[FRAME_COUNT] =
{
[FRAME_A] =
{
.id = MCM_FRAMEID_A,
// And other stuff
},
[FRAME_B] =
{
.id = MCM_FRAMEID_B,
// And other stuff
},
[FRAME_C] =
{
.id = MCM_FRAMEID_C,
// And other stuff
}
}
Finally the the ID to frame_e function:
frame_e UAR_FrameId2Frame(frameId_e id)
{
frame_e frame = (frame_e) 0;
while(FramesInfo[frame].id != id && frame < FRAME_COUNT)
{
frame = (MCM_frames_e)(frame + 1);
}
return frame;
}

Answer 1

I don't get any warnings here:
#include <stdio.h>
typedef enum myEnum_e
{
VAL0,
VAL1
} myEnum;
int main (int argc, char *argv[]) {
myEnum val = 0;
while( 1 /*Do something*/)
{
val = val + 1;
}
return 0;
}
Compiler: GCC 4.2.1
Compile command: gcc -Wall -pedantic x.c

Answer 2

It's a good thing that you are getting a warning.C is not a strictly typed language so you don't get errors when mixing types that can be coerced into one another. But mixing types has the potential to cause subtle runtime errors. So, although internally enums and integers are same types, you shouldn't be mixing them. You should consider using an enum increment variable initialized to 1.

Answer 3

First of all, having code with a lot of casts is not very pleasant to read, but well, that's just a matter of taste.
If you plan to do arithmetic you might want to explicitly define values for the enums. It's risky to do this anyway, because you could end up with an out-of-range values.
What if you add 3 to your VAL0?
Think about it, what does that mean? You've declared an enum, but the value that you now got is not a valid enum anymore. The reason to use an enum is mostly that you want to limit the number of possible values for an ordinal.
In your situation it makes more sense to have constants like VAL0 and VAL1.
Or, if all you needed was to iterate over your enum, you could do this:
typedef enum myEnum_e
{
VAL0,
VAL1,
// ...
VAL66
} myEnum;
for(int i=VAL0; i<=VAL66; i++) {
// do something here
}