Unreachable code

Unreachable code can exist for many reasons, such as: • programming errors in complex conditional branches • a consequence of the internal transformations performed by an optimizing compiler; • incomplete testing of new or modified code • Legacy code • Code superseded by another implementation • Unreachable code that a programmer decided not to delete because it is mingled with reachable code • Potentially reachable code that current use cases never need • Dormant code that is kept intentionally in case it is needed later • Code used only for debugging. Legacy code is that which was once useful but is no longer used or required. But unreachable code may also be part of a complex library, module or routine where it is useful to others or under conditions which are not met in a particular scenario. An example of such a conditionally unreachable code may be the implementation of a general string formatting function in a compiler's runtime library, which contains complex code to process all possible arguments, of which only a small subset is actually used. Compilers will typically not be able to remove the unused code sections at compile time, as the behavior is largely determined by the values of arguments at run time. ==Examples==

In this fragment of C code: int foo(int x, int y) { return x + y; int z = x + y; } the definition int z = x + y; is never reached as the function always returns before it. Therefore, variable z neither needs to be allocated storage nor initialized. goto fail bug Apple's SSL/TLS from February 2014 contained a major security flaw known formally as and informally as the "goto fail bug". The relevant code fragment is: static OSStatus SSLVerifySignedServerKeyExchange(SSLContext* ctx, bool isRsa, SSLBuffer signedParams, uint8_t* signature, uint16_t signatureLen) { OSStatus err; // ... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; // ... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; } Here, there are two successive goto fail statements. In the syntax of the C language, only the first statement after an un-braced if statement is conditional. The second goto fail is therefore unconditional, and hence always skips the call to SSLHashSHA1.final. As a consequence, err will hold the status of the SHA1 update operation, and as long as both calls to SSLHashSHA1.update succeed, signature verification will never fail. ==Analysis==

Detection of unreachable code is a form of control flow analysis to find code that can never be reached in any possible program state. In some languages (e.g. Java) some forms of unreachable code are explicitly disallowed. The optimization that removes unreachable code is known as dead code elimination. Code may become unreachable as a consequence of transformations performed by an optimizing compiler (e.g., common subexpression elimination). In practice the sophistication of the analysis has a significant impact on the amount of unreachable code that is detected. For example, constant folding and simple flow analysis shows that the inside of the if-statement in the following code is unreachable: int n = 2 + 1; if (n == 4) { // unreachable } However, a great deal more sophistication is needed to work out that the corresponding block is unreachable in the following code: • include double x = sqrt(2); if (x > 5) { // unreachable } Unreachable code elimination technique is in the same class of optimizations as dead code elimination and redundant code elimination. Some languages allow explicitly marking code as unreachable: • C: via the unreachable() macro (in ) • C++: via the std::unreachable() function (in ), which is noreturn • C#: can be indicated using the System.Diagnostics.Debug class, using the Debug.Fail() method • Java: usually marked by throwing the java.lang.AssertionError exception • Rust: via the unreachable!() macro • Swift: via fatalError(), or functions returning Never • Zig: via the unreachable keyword Unreachability vs. profiling In some cases, a practical approach may be a combination of simple unreachability criteria and use of a profiler to handle the more complex cases. Profiling in general can not prove anything about the unreachability of a piece of code, but may be a good heuristic for finding potentially unreachable code. Once a suspect piece of code is found, other methods, such as a more powerful code analysis tool, or even analysis by hand, could be used to decide whether the code is truly unreachable. ==See also==