Editing Unreachable code (section)

==Examples==
In this fragment of C code:

<syntaxhighlight lang="C">
int foo (int X, int Y)
{
    return X + Y;
    int Z = X * Y;
}
</syntaxhighlight>

the definition {{mono|int Z {{=}} X * Y;}} is never reached as the function always returns before it. Therefore, the {{mono|Z}} need be neither allocated storage nor initialized.

===goto fail bug===
<!-- Courtesy note per [[WP:RSECT]]: [[goto fail]] links here -->
Apple's [[Transport Layer Security|SSL/TLS]] from February 2014 contained a major security flaw known formally as {{CVE|2014-1266}} and informally as the "goto fail bug".<ref name="gotofail">{{cite web|author=Adam Langley|year=2014|title=Apple's SSL/TLS bug|url=https://www.imperialviolet.org/2014/02/22/applebug.html}}</ref><ref name="gotofail_lessons">{{cite web|author=Arie van Deursen|year=2014|title=Learning from Apple's #gotofail Security Bug|url=http://avandeursen.com/2014/02/22/gotofail-security/}}</ref> 
The relevant code fragment<ref>{{cite web|title=sslKeyExchange.c - Source code for support for key exchange and server key exchange|url=http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c?txt}}</ref>
is:

<syntaxhighlight lang="c" highlight="12">
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;
}
</syntaxhighlight>

Here, there are two successive <code>goto fail</code> statements. In the syntax of the C language, the second is unconditional, and hence ''always'' skips the call to <code>SSLHashSHA1.final</code>.
As a consequence, <code>err</code> will hold the status of the SHA1 update operation, and signature verification will ''never'' fail.<ref name=gotofail/>

Here, the unreachable code is the call to the <code>final</code> function.<ref name=gotofail_lessons/> Applying the [[Clang]] compiler with the option <code>-Weverything</code> includes unreachable code analysis, which would trigger an alarm for this code.<ref name=gotofail_lessons/>

===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.<ref>{{cite web|url=https://wiki.sei.cmu.edu/confluence/display/c/MSC15-C.+Do+not+depend+on+undefined+behavior|publisher=Carnegie Mellon University|title=MSC15-C. Do not depend on undefined behavior|quote=Because compilers are not obligated to generate code for undefined behavior, these behaviors are candidates for optimization.|year=2020|access-date=28 September 2020}}</ref>