|
Unreachable codeIn computer programming, unreachable code is part of the source code of a program which can never be executed because there exists no control flow path to the code from the rest of the program.[1] Unreachable code is sometimes also called dead code,[2][3] although dead code may also refer to code that is executed but has no effect on the output of a program.[4] Unreachable code is generally considered undesirable for several reasons:
Unreachable code can have some legitimate uses, like providing a library of functions for calling or jumping to manually via a debugger while the program is halted after a breakpoint. This is particularly useful for examining and pretty-printing the internal state of the program. It may make sense to have such code in the shipped product, so that a developer can attach a debugger to a client's running instance. CausesUnreachable code can exist for many reasons, such as:
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. ExamplesIn 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, the Z need be neither allocated storage nor initialized. goto fail bugApple's SSL/TLS from February 2014 contained a major security flaw known formally as CVE-2014-1266 and informally as the "goto fail bug".[5][6] The relevant code fragment[7] is: static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
uint8_t *signature, UInt16 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 Here, the unreachable code is the call to the C++In C++, some constructs are specified to have undefined behavior. A compiler is free to implement any behavior or none, and typically an optimizing compiler will assume the code is unreachable.[8] AnalysisDetection 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[9]) 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: 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. Unreachability vs. profilingIn 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
References
|