209

Through a little typo, I accidentally found this construct:

int main(void) { char foo = 'c'; switch(foo) { printf("Cant Touch This\n"); // This line is Unreachable case 'a': printf("A\n"); break; case 'b': printf("B\n"); break; case 'c': printf("C\n"); break; case 'd': printf("D\n"); break; } return 0; }

It seems that the printf at the top of the switch statement is valid, but also completely unreachable.

I got a clean compile, without even a warning about unreachable code, but this seems pointless.

Should a compiler flag this as unreachable code?
Does this serve any purpose at all?

Improve this question
18
  • 53
    GCC has a special flag for this. It's -Wswitch-unreachable Commented Jan 18, 2017 at 19:08
  • 59
    "Does this serve any purpose at all?" Well, you can goto in and out of the otherwise unreachable part, which may be useful for various hacks. Commented Jan 18, 2017 at 19:09
  • 14
    @HolyBlackCat Wouldn't that be such for all unreachable code? Commented Jan 18, 2017 at 19:10
  • 29
    @EliSadoff Indeed. I guess it doesn't serve any special purpose. I bet it is allowed just because there is no reason to forbid it. After all, switch is just a conditional goto with multiple labels. There are more or less same restrictions on it's body as you would have on a regular block of code filled with goto labels. Commented Jan 18, 2017 at 19:14
  • 17
    Worth pointing out that @MooingDuck s example is a variant on Duff's device (en.wikipedia.org/wiki/Duff's_device) Commented Jan 19, 2017 at 2:14

8 Answers 8

Reset to default
229

Perhaps not the most useful, but not completely worthless. You may use it to declare a local variable available within switch scope.

switch (foo) { int i; case 0: i = 0; //.... case 1: i = 1; //.... }

The standard (N1579 6.8.4.2/7) has the following sample:

EXAMPLE    In the artificial program fragment

switch (expr) { int i = 4; f(i); case 0: i = 17; /* falls through into default code */ default: printf("%d\n", i); }

the object whose identifier is i exists with automatic storage duration (within the block) but is never initialized, and thus if the controlling expression has a nonzero value, the call to the printf function will access an indeterminate value. Similarly, the call to the function f cannot be reached.

P.S. BTW, the sample is not valid C++ code. In that case (N4140 6.7/3, emphasis mine):

A program that jumps90 from a point where a variable with automatic storage duration is not in scope to a point where it is in scope is ill-formed unless the variable has scalar type, class type with a trivial default constructor and a trivial destructor, a cv-qualified version of one of these types, or an array of one of the preceding types and is declared without an initializer (8.5).

90) The transfer from the condition of a switch statement to a case label is considered a jump in this respect.

So replacing int i = 4; with int i; makes it a valid C++.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

"... but is never initialized ..." Looks like i is initialized to 4, what am I missing?
Note that if the variable is static, it will be initialized to zero, so there's a safe usage for this as well.
@yano We always jump over the i = 4;initialization, so it never takes place.
Hah of course! ... whole point of the question ... geez. The desire is strong to delete this stupidity
Nice! Sometimes I needed a temp variable inside a case, and always had to use different names in each case or define it outside the switch.
99

Does this serve any purpose at all?

Yes. If instead of a statement, you put a declaration before the first label, this can make perfect sense:

switch (a) { int i; case 0: i = f(); g(); h(i); break; case 1: i = g(); f(); h(i); break; }

The rules for declarations and statements are shared for blocks in general, so it's the same rule that allows that that also allows statements there.

Worth mentioning as well is also that if the first statement is a loop construct, case labels may appear in the loop body:

switch (i) { for (;;) { f(); case 1: g(); case 2: if (h()) break; } }

Please don't write code like this if there is a more readable way of writing it, but it's perfectly valid, and the f() call is reachable.

Improve this answer

3 Comments

@MatthieuM Duff's Device does have case labels inside a loop, but starts with a case label before the loop.
I'm not sure if I should upvote for the interesting example or downvote for the utter madness of writing this in a real program :). Congrats for diving into the abyss and returning back in one piece.
@ChemicalEngineer: If the code is part of a loop, as it is in Duff's Device, { /*code*/ switch(x) { } } may look cleaner but it is also wrong.
39

There is a famous use of this called Duff's Device.

int n = (count+3)/4; switch (count % 4) { do { case 0: *to = *from++; case 3: *to = *from++; case 2: *to = *from++; case 1: *to = *from++; } while (--n > 0); }

Here we copy a buffer pointed to by from to a buffer pointed to by to. We copy count instances of data.

The do{}while() statement starts before the first case label, and the case labels are embedded within the do{}while().

This reduces the number of conditional branches at the end of the do{}while() loop encountered by roughly a factor of 4 (in this example; the constant can be tweaked to whatever value you want).

Now, optimizers can sometimes do this for you (especially if they are optimizing streaming/vectorized instructions), but without profile guided optimization they cannot know if you expect the loop to be large or not.

In general, variable declarations can occur there and be used in every case, but be out of scope after the switch ends. (note any initialization will be skipped)

In addition, control flow that isn't switch-specific can get you into that section of the switch block, as illustrated above, or with a goto.

Improve this answer

4 Comments

Of course, this would still be possible without allowing statements above the first case, as the order of do { and case 0: don't matter, both serve to place a jump target on the first *to = *from++;.
@BenVoigt I'd argue that putting the do { is more readable. Yes, arguing about readability for Duff's Device is stupid and pointless and likely a simple way to go mad.
@QPaysTaxes You should check out Simon Tatham’s Coroutines in C. Or maybe not.
@JonasSchäfer Amusingly, that is basically what C++20 coroutines are going to do for you.
15

Assuming you are using gcc on Linux, it would have given you a warning if you're using 4.4 or earlier version.

The -Wunreachable-code option was removed in gcc 4.4 onward.

Improve this answer

6 Comments

Having experienced the issue first hand always helps!
@JonathanLeffler: The general issue of gcc warnings being susceptible to the particular set of optimization passes selected is still true, unfortunately, and makes for a poor user experience. It's really annoying to have a clean Debug build followed by a failing Release build :/
@MatthieuM.: It would seem that such a warning would be extremely easy to detect in cases involving grammatical rather than semantic analysis [e.g. code follows an "if" which has returns in both branches], and make it easier to stifle "annoyance" warnings. On the other hand, there are some cases where it's useful to have errors or warning in release builds that aren't in debug builds (if nothing else, in places where a hack which is put in for debugging is supposed to be cleaned up for release).
@MatthieuM.: If significant semantic analysis would be required to discover that a certain variable will always be false at some spot in the code, code which is conditional upon that variable being true would be found to be unreachable only if such analysis were performed. On the other hand, I would consider a notice that such code was unreachable rather differently from a warning about syntactically-unreachable code, since it should be entirely normal to have various conditions be possible with some project configurations but not others. It may at times be helpful for programmers...
...to know why some configurations generate larger code than others [e.g. because a compiler could regard some condition as impossible in one configuration but not another] but that doesn't mean that there's anything "wrong" with code which could be optimized in that fashion with some configurations.
|
11

Not only for variable declaration but advanced jumping as well. You can utilize it well if and only if you're not prone to spaghetti code. 

int main() { int i = 1; switch(i) { nocase: printf("no case\n"); case 0: printf("0\n"); break; case 1: printf("1\n"); goto nocase; } return 0; }

Prints

1 no case 0 /* Notice how "0" prints even though i = 1 */

It should be noted that switch-case is one of the fastest control flow clauses. So it must be very flexible to the programmer, which sometimes involves cases like this.

Improve this answer

5 Comments

And what is difference between nocase: and default:?
@i486 Wheni=4 it does not trigger nocase.
@SanchkeDellowar that's what I mean.
Why the heck would one do that instead of simply putting case 1 before case 0 and using fallthrough?
@JonasWielicki In this objective, you could do that. But this code is just a display case of what can be done.
11

It should be noted, that there are virtually no structural restrictions on the code within the switch statement, or on where the case *: labels are placed within this code*. This makes programming tricks like duff's device possible, one possible implementation of which looks like this:

int n = ...; int iterations = n/8; switch(n%8) { while(iterations--) { sum += *ptr++; case 7: sum += *ptr++; case 6: sum += *ptr++; case 5: sum += *ptr++; case 4: sum += *ptr++; case 3: sum += *ptr++; case 2: sum += *ptr++; case 1: sum += *ptr++; case 0: ; } }

You see, the code between the switch(n%8) { and the case 7: label is definitely reachable...

* As supercat thankfully pointed out in a comment: Since C99, neither a goto nor a label (be it a case *: label or not) may appear within the scope of a declaration that contains a VLA declaration. So it's not correct to say that there are no structural restrictions on the placement of the case *: labels. However, duff's device predates the C99 standard, and it does not depend on VLA's anyway. Nevertheless, I felt compelled to insert a "virtually" into my first sentence due to this.

Improve this answer

5 Comments

The addition of variable-length arrays led to the imposition of structural restrictions related to them.
@supercat What kind of restrictions?
Neither a goto nor switch/case/default label may appear within the scope of any variably-declared object or type. This effectively means that if a block contains any declarations of variable-length-array objects or types, any labels must precede those declarations. There's a confusing bit of verbiage in the Standard which would suggest that in some cases the scope of a VLA declaration extends to the entirety of a switch statement; see stackoverflow.com/questions/41752072/… for my question on that.
@supercat: You just misunderstood that verbiage (which I presume is why you deleted your question). It imposes a requirement on the scope in which a VLA may be defined. It doesn't extend that scope, it just makes certain VLA definitions invalid.
@KeithThompson: Yeah, I had misunderstood it. The weird use of the present tense in the footnote made things confusing, and I think the concept could have been better expressed as a prohibition: "A switch statement whose body contains a VLA declaration within it shall not include any switch or case labels within the scope of that VLA declaration".
10

You got your answer related to the required gcc option -Wswitch-unreachable to generate the warning, this answer is to elaborate on the usability / worthyness part.

Quoting straight out of C11, chapter §6.8.4.2, (emphasis mine)

switch (expr) { int i = 4; f(i); case 0: i = 17; /* falls through into default code */ default: printf("%d\n", i); }

the object whose identifier is i exists with automatic storage duration (within the block) but is never initialized, and thus if the controlling expression has a nonzero value, the call to the printf function will access an indeterminate value. Similarly, the call to the function f cannot be reached.

Which is very self-explanatory. You can use this to define a locally scoped variable which is available only within the switch statement scope.

Improve this answer

Comments

9

It is possible to implement a "loop and a half" with it, although it might not be the best way to do it:

char password[100]; switch(0) do { printf("Invalid password, try again.\n"); default: read_password(password, sizeof(password)); } while (!is_valid_password(password));
Improve this answer

2 Comments

@RichardII Is it a pun or what? Please explain.
@Dancia He's saying that this is pretty clearly not the best way to do something like this, and "might not" is something of an understatement.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.