Consider the following enum and switch statement:
typedef enum {
MaskValueUno,
MaskValueDos
} testingMask;
void myFunction(testingMask theMask) {
switch (theMask) {
case MaskValueUno: {}// deal with it
case MaskValueDos: {}// deal with it
default: {} //deal with an unexpected or uninitialized value
}
};
I'm an Objective-C programmer, but I've written this in pure C for a wider audience.
Clang/LLVM 4.1 with -Weverything warns me at the default line:
Default label in switch which covers all enumeration values
Now, I can sort of see why this is there: in a perfect world, the only values entering in the argument theMask
would be in the enum, so no default is necessary. But what if some hack comes along and throws an uninitialized int into my beautiful function? My function will be provided as a drop in library, and I have no control over what could go in there. Using default
is a very neat way of handling this.
Why do the LLVM gods deem this behaviour unworthy of their infernal device? Should I be preceding this by an if statement to check the argument?
Best Answer
Here's a version that suffers from neither the problem clang's reporting or the one you're guarding against:
Killian has explained already why clang emits the warning: if you extended the enum, you'd fall into the default case which probably isn't what you want. The correct thing to do is to remove the default case and get warnings for unhandled conditions.
Now you're concerned that someone could call your function with a value that's outside the enumeration. That sounds like failing to meet the function's prerequisite: it's documented to expect a value from the
testingMask
enumeration but the programmer has passed something else. So make that a programmer error usingassert()
(orNSCAssert()
as you said you're using Objective-C). Make your program crash with a message explaining that the programmer is doing it wrong, if the programmer does it wrong.