This bug was frustrating enough that half-way through squashing it, I promised myself I would document the solution. Unfortunately, it’s not a particularly interesting bug, but a promise is a promise!<\/p>\n
I had some code very much like: NetworkError: default: int main (int argc, char** argv) And it just wouldn’t do the right thing, but for the life of me I couldn’t see what was wrong.<\/p>\n The “solution” was very simple, and somewhat embarrassing. I forgot the
\n
\ntypedef enum {NoError, ReadError, WriteError, NetworkError, UnknownError} ErrorType;
\n...
\nvoid DescriptionOfError(ErrorType err, char *string)
\n{
\n switch(err)
\n {
\n IOError:
\n strcpy(string, \"Could not read data.\");
\n break;
\n
\n WriteError:
\n strcpy(string, \"Could not write data!\");
\n break;<\/p>\n
\n strcpy(string, \"Network Error. Make sure you have an internet connection and try again\");
\n break;
\n
\n NoError:
\n strcpy(string, \"No error.\");
\n break;<\/p>\n
\n UnknownError:
\n strcpy(string, \"Unknown error.\");
\n break;
\n }
\n}<\/p>\n
\n{
\n char desc[1024];
\n DescriptionOfError(ReadError,desc);
\n printf(\"error: %s\\n\", desc);
\n return 0;
\n}
<\/code><\/p>\ncase<\/strong><\/code> keyword before the labels in the switch<\/code> statement. Turns out that if you don’t have a case<\/code> in-front of a label, it’s treated like a goto<\/code> label, not a switch<\/code> label. And this is something that I’ve known for years, but for 20 minutes I kept reading<\/em> the code, and my brain would interpret what it should say, not literally analyze it.<\/p>\n