Why do (or don't) languages forbid unreachable code?

Question

In Java, the following is a compile-time error, due to the unreachable statement:

while(true) {
    break;
    System.out.println("unreachable");
}

In Rust, the equivalent code is not:

loop {
    break;
    println!("unreachable");
}

In general, determining reachability is undecidable; however, that doesn't stop compilers from applying rules which can statically detect some but not all unreachable code. The Rust compiler already has logic for this, in order to emit a warning (and also to discard the unreachable code), but the same logic is not used to emit an error message. So in Rust and likely many other cases, this is a design decision, not a feasibility issue.

What reasons have the designers of languages given for or against emitting errors for unreachable code? I'm particularly interested in the rationales for mainstream languages which either do make this an error, or which don't but have plenty of other static checks; authoritative answers about other languages are also welcome.

Answer 1

Great question. I can tell you a bit about C# and why in C#, unreachable code is a warning, not an error. I'll start by briefly describing how reachability detection works, then what it is used for, and then why it's a warning, not an error.

Unreachable code is detected by a few relatively simple rules. The simplest are ones like the case you describe; we can very easily partition statements into "blocks" where control enters at the top of the block and does not leave normally (that is, without an exception) until the end of the block. If no control flow enters the top of a basic block, the whole block is unreachable.

Those statements that always "go somewhere else" (goto, return, break, continue, throw) are said to have an "unreachable endpoint". As does any statement that is itself unreachable.

Next, C# does an analysis of compile-time constant expressions; these are expressions involving only literals or named constants. The else block of an if(0==0) condition is unreachable, but C# would consider the else block of if(x * 0 == 0) for integer variable x to be reachable, since the expression is not a constant expression. (Fun fact, C# 1 and 2 had a bug where it ran the arithmetic optimizer too early and treated some expressions of this form as constants; I fixed it for C# 3.) while(true) {} has an unreachable endpoint.

C# also analyzes the logical or/and expressions to determine reachability, which is where the rules get a little complicated; see the spec for details.

And let me finish this brief overview with the puzzle I always pose when discussing reachability. There is a C# program where there is a reachable goto, but its target label is unreachable. Can you give an example of such a program?

---

Why does C# care about reachability at all?

• The end point of the last statement in a method with a non-void return type must be unreachable, otherwise we have a bug; the method doesn't necessarily return a value.

• If the end point of the last statement in a method is reachable then every out parameter must be definitely assigned before that, otherwise we have a bug, we are possibly returning without assigning the out parameter.

• In C and C++, the switch statement is bug prone. In a switch in C, each label starts a section, that section can be empty, and so in order to have two labels with the same consequence, control must fall through from the bottom of one section to the next. C# fixes this logical problem by instead saying that a section is never empty; it always has at least one statement, and that a section may have multiple labels. A section must have an unreachable endpoint.

• C# disallows reading from a local variable before it is known to have been assigned, again because this is a common source of bugs. The rules that determine when a variable is known to be assigned and known to be read are based on reachability analysis. If there is a possibly-reachable read where the corresponding write is unreachable or possibly unreachable, that's an error. But a read of a possibly-unassigned local is not an error if the read itself is unreachable.

What I'm getting at here is: we care about reachability analysis because it enables automatically finding common bugs and preventing them at compile time. But why then is unreachable code not itself a bug that makes a compile-time error? And why is reading from an unassigned local legal in unreachable code?

---

To facilitate debugging! I'm sure you've encountered this situation of:

if(some complicated and hard to reproduce condition)
{
  there's a bug in this code
} else {
  some perfectly normal code
}

If the repro is a pain, the natural thing to do is to just write

if(true /* painful repro condition */)
{
  // put your breakpoint here
  there's a bug in this code
} else {
  some perfectly normal code
}

If that's a compile-time error because the else case is now unreachable, then you're slowing down the debugging process. If it is not a warning, then you're risking the developer accidentally checking in debug code. Therefore the sensible thing to do is to make it a warning.

Same with unassigned locals.

int x;
if (Validate(y, out x))
{
  do something with x
} else {
  uh oh the error case has a bug in it
  but it does not read x
}

We quickly debug it by

int x;
if (false /*Validate(y, out x)*/)
{
  do something with x
} else {
  // breakpoint here
  uh oh the error case has a bug in it
  but it does not read x   
}

In this debugging scenario "do something with x" reads x before it is assigned. Doesn't matter! Reading a variable before it is assigned in unreachable code is not an error. Rather, the unreachable code is a warning so that you don't check it in by mistake.

There are other scenarios as well; here's one I described in 2012.

---

The lesson for language designers here is to think about everything that a developer is going to do. Code is not just written and checked in; it's modified in temporary ways during debugging, often under time pressure, and anything we can do to make that process easier makes developers more productive.

---

If this subject interests you, I've written about it a fair amount. A good start is this now-deleted post on the Coverity blog:

https://web.archive.org/web/20140331160029/http://blog.coverity.com/2013/11/06/c-reachability#.UzmRJ4HP1qY

Answer 2

Because it's not uncommon to create unreachable code deliberately. Sometimes it's just temporary during incremental development, sometimes it's permanent.

For instance, you might have code like

if (DEBUG) {
    // do stuff
}

When the DEBUG macro expands to false all this code is unreachable.

Sometimes you have code like

if (condition) {
    // do stuff
}

and you want to temporarily disable it. So you change the first line to

if (false && (condition)) {

There are other ways to accomplish this, such as testing the macro in the preprocessor, or commenting out the whole block of code. But doing it like this is often preferable because the block structure of the code is preserved.

Answer 3

In languages that have a preprocessor, templates or macros, unreachable code often occurs without being an issue:

• Configuration options checked with #ifdef can affect what code is run. It's not always reasonable to #ifdef out the unreachable code, as the condition could get much more complex than the individual checks.
• Target platform affects the size of types like int, which causes unreachable branches in checks based on sizeof(int). This is usually indicative of the opposite of a bug: the code deliberately handles platform differences by checking the size.
• C++ templates can result in unreachable code by checking the properties of types, or by numeric range limitations.
• Compiler optimizations and inlining result in unreachable code when functions or macros are used in specific cases.

That said, many C and C++ compilers do support a warning about unreachable code, and usually also allow configuring warnings as errors.

Answer 4

I'll come at this from a primarily C perspective.

In general, determining reachability is undecidable; however, that doesn't stop compilers from applying rules which can statically detect some but not all unreachable code.

Many programming languages predate the existence of compilers that could do that sort of detection. Early C compilers didn't perform any real optimization at all, they just translated what's on the page directly to assembly. Forbidding unreachable code would be a rule that was impossible to enforce, thus pointless. Even in the modern era, trying to enforce this rule can result in code that compiles on one compiler and not on another. That makes things unnecessarily difficult for the programmer. This could even happen on the same compiler between two different sets of compiler options.

This becomes even more of a problem when you start trying to write code that's reusable or cross-platform. The C preprocessor allows you to #ifdef chunks of code and hide them, but that preprocessor is extremely primitive. It's not uncommon to need to gate a chunk of code using logic that can be resolved at compile time, but is much more sophisticated than what the preprocessor is capable of. Oversimplified example:

void transmit_token(token *tok) /* platform-specific typedef */
{
    queue_token(tok);
    // Receiving device expects a 32-bit transmission,
    // insert padding bytes if necessary.
    for (uint i = 0; i < (4 - sizeof(*tok)); ++i)
        queue_byte(PAD_BYTE);
    transmit_waiting_bytes();
}

When data type token is 32 bits long, the compiler can easily tell that the for loop is dead code. The preprocessor has no knowledge of types and can't evaluate a statement that complex, so if dead code was forbidden you'd have to write something like this instead:

void transmit_token(token *tok) /* platform-specific typedef */
{
    queue_token(tok);
    // Receiving device expects a 32-bit transmission,
    // insert padding bytes if necessary.
#if defined TOKEN_IS_ONE_BYTE
    queue_byte(PAD_BYTE);
    queue_byte(PAD_BYTE);
    queue_byte(PAD_BYTE);
#elif defined TOKEN_IS_TWO_BYTES
    queue_byte(PAD_BYTE);
    queue_byte(PAD_BYTE);
#elif defined TOKEN_IS_THREE_BYTES
    queue_byte(PAD_BYTE);
#endif
    transmit_waiting_bytes();
}

Gross. Not only is it far more complex and copy/paste-y, but now I have to manually define a boat load of platform-specific preprocessor constants. That introduces a lot of opportunity for human error (don't ask how I know). When porting this code to a new platform, I now have to read through the entire codebase and determine which lines need platform-specific modifications vs. having a generic version of the code that just works.

On projects that I've worked on personally, a hard rule against dead code would have prevented me from having re-usable code libraries. I would have needed to maintain separate x86, PPC, and MIPS versions of my library code, and then somehow manually keep them all in sync at all times. That quickly turns into a bug farm. Instead, I had a single library that could be built for all platforms. Some of the code was unreachable for some platforms, but that's perfectly OK. The compiler detected it and cut it out automatically.

Forbidding dead code could even have legal consequences. Let's say that you're using a third-party library and the compiler detects dead code in a library header (including a header in C essentially pastes its contents into your source file, so the compiler processes it just like the rest of your code) for your particular combination of platform, compiler, and compile options. What do you do? Modify the header to remove the dead code? A library with a proprietary license likely doesn't give you the rights to make modifications at all. If the library is using something like the LGPL, modifying it would be considered creating a derivative work and would then require you to publish your source code and do other things that may not be desirable. All just to get around a compiler error that's complaining about something that isn't actually a problem. Even if I did have the rights to modify the header, I may not have the source for the library itself. How do I know my changes aren't breaking something?

At the end of the day, dead code is really only a problem if it's unintentionally dead. The drawbacks of throwing a compiler error here far outweigh the benefits. That's not to say that C programmers don't care about dead code, we just use a static analyzer for that and not the compiler.

Answer 5

In Python, only syntax errors and warnings can happen at compile time, and unreachable code wouldn't qualify as a syntactic issue. So reachability analysis simply isn't done. It's designed like this for a few reasons:

• It simplifies understanding of error messages, and lets one get to the unit tests faster.

• Everything is so dynamic that it would be hard to prove (non)reachability in pathological cases, anyway. For example, a name for a global variable could be read from a file and used to update the globals() dict, subsequently impacting an if condition later in the same function.

• Since things are so dynamic, there is at least some pressure to make compilation fast, since it happens frequently and as part of the execution of the program (rather than all ahead of time).

• There is no pressure from correctness requirements, largely due to dynamic typing. For example, there's no problem of "if a non-void function reaches the end without reaching return then it would be a bug for the compiler to accept that" - because every function is non-void, and every function may return a value of any type, and there is a specific value dedicated for the purpose of being the return value of functions that reach the end without encountering return (i.e., None).

• Having bytecode that closely reflects the structure of the code is considered an advantage for debugging. Very little optimization is done at the level of peephole optimization of bytecode; the optimization work is focused on the design of the virtual instruction set itself, and on the code that interprets those bytecodes. Even the "optimization" flags only strip out some metadata from the resulting .pyc files. There are some very specific hard-coded cases: e.g. code inside if False: will be optimized out, but code inside even something as trivial as if 1 == 1: will not.

Answer 6

Since unreachable code detection is undecidable, as a compiler evolves the detection algorithm can become better and/or worse. It would be a bad idea to have code that compiles successfully on one version and fails on the next simply because the compiler got smarter at detecting unreachable code.

Answer 7

The only problem that would be solved by prohibiting unreachable code would be to prevent bloated executables.

That's a performance issue. Compilers aren't supposed to stop the developer from being inefficient.