为什么无法通过编译器完全解决死代码检测？

我在C或Java中使用的编译器具有防止死代码的功能（警告将永远不会执行任何行）。我的教授说，尽管如此，编译器永远无法完全解决这个问题。我想知道为什么会这样。我对编译器的实际编码不太熟悉，因为这是一个基于理论的类。但是我想知道他们检查什么（例如可能的输入字符串与可接受的输入等），以及为什么这样做不够。

无效代码问题与停止问题有关。

艾伦·图灵（Alan Turing）证明，不可能编写一种通用算法，该算法将被赋予程序并能够决定该程序是否停止所有输入。您可能可以为特定类型的程序编写这样的算法，但不能为所有程序编写。

这与无效代码有何关系？

停止问题可以简化为找到无效代码的问题。也就是说，如果找到一种可以检测任何程序中的无效代码的算法，则可以使用该算法测试任何程序是否将停止。既然已经证明这是不可能的，那么随之而来的是为死代码编写算法也是不可能的。

如何将死代码算法转换为停止问题算法？

简单：在要检查暂停的程序结束后添加一行代码。如果您的死代码检测器检测到该行已死，则说明程序不会停止。如果不是，则您知道程序停止了（进入最后一行，然后到达添加的代码行）。

编译器通常检查在编译时可以证明是死的东西。例如，取决于在编译时可以确定为假的条件的块。或之后的任何语句return（在相同范围内）。

这些是特定情况，因此可以为它们编写算法。可以为更复杂的情况编写算法（例如检查条件是否在语法上是矛盾的，因此总是返回false的算法），但是仍然不能涵盖所有可能的情况。

好吧，让我们以经典的证据证明停止问题的不确定性，然后将停止检测器更改为死代码检测器！

C＃程序

using System;
using YourVendor.Compiler;

class Program
{
    static void Main(string[] args)
    {
        string quine_text = @"using System;
using YourVendor.Compiler;

class Program
{{
    static void Main(string[] args)
    {{
        string quine_text = @{0}{1}{0};
        quine_text = string.Format(quine_text, (char)34, quine_text);

        if (YourVendor.Compiler.HasDeadCode(quine_text))
        {{
            System.Console.WriteLine({0}Dead code!{0});
        }}
    }}
}}";
        quine_text = string.Format(quine_text, (char)34, quine_text);

        if (YourVendor.Compiler.HasDeadCode(quine_text))
        {
            System.Console.WriteLine("Dead code!");
        }
    }
}

如果YourVendor.Compiler.HasDeadCode(quine_text)return false，则该行将System.Console.WriteLn("Dead code!");永远不会执行，因此该程序实际上确实具有无效代码，并且检测器错误。

但是，如果返回true，则将System.Console.WriteLn("Dead code!");执行该行，并且由于程序中没有更多代码，因此根本没有死代码，因此检测器还是错误的。

因此，有了死代码检测器，它仅返回“存在死代码”或“没有死代码”有时必须产生错误的答案。

如果停止问题太晦涩难懂，请以这种方式考虑。

采取一个数学问题，该问题被认为对所有正整数n都成立，但尚未证明对每一个n都成立。哥德巴赫猜想就是一个很好的例子，任何大于2的正偶整数都可以用两个质数之和表示。然后（使用适当的bigint库）运行此程序（后接伪代码）：

 for (BigInt n = 4; ; n+=2) {
     if (!isGoldbachsConjectureTrueFor(n)) {
         print("Conjecture is false for at least one value of n\n");
         exit(0);
     }
 }

实施isGoldbachsConjectureTrueFor()就留给读者做练习，但为此目的可能是在所有的素数进行简单迭代小于n

现在，从逻辑上讲，以上内容必须等于：

 for (; ;) {
 }

（即无限循环）或

print("Conjecture is false for at least one value of n\n");

因为哥德巴赫的猜想必须是正确的或不正确的。如果编译器始终可以消除无效代码，则无论哪种情况，肯定都需要消除无效代码。但是，这样做至少会使您的编译器需要解决任意困难的问题。我们可以提供问题可证明的辛苦，那就要解决（如NP完全问题）来确定的码位以消除。例如，如果我们采用以下程序：

 String target = "f3c5ac5a63d50099f3b5147cabbbd81e89211513a92e3dcd2565d8c7d302ba9c";
 for (BigInt n = 0; n < 2**2048; n++) {
     String s = n.toString();
     if (sha256(s).equals(target)) {
         print("Found SHA value\n");
         exit(0);
     }
 }
 print("Not found SHA value\n");

我们知道该程序将打印出“找到的SHA值”或“找不到SHA值”（如果您能告诉我哪个是正确的，请加分）。但是，为了使编译器能够合理地优化，需要进行2 ^ 2048次迭代。实际上，这将是一个巨大的优化，因为我预计上述程序将（或可能）运行到宇宙热死为止，而不是在没有优化的情况下打印任何内容。

我不知道C ++或Java是否具有Eval类型函数，但是许多语言都允许您通过name调用方法。考虑下面的（人为）VBA示例。

Dim methodName As String

If foo Then
    methodName = "Bar"
Else
    methodName = "Qux"
End If

Application.Run(methodName)

直到运行时才知道要调用的方法的名称。因此，根据定义，编译器无法绝对确定地知道永远不会调用特定方法。

实际上，以通过名称调用方法的示例为例，甚至不需要分支逻辑。简单地说

Application.Run("Bar")

是编译器无法确定的。编译代码时，所有编译器都知道将某个字符串值传递给该方法。它直到运行时才检查该方法是否存在。如果未在其他地方调用该方法，则通过更常规的方法，尝试查找无效方法可能会返回误报。任何允许通过反射调用代码的语言都存在相同的问题。

高级编译器可以检测和删除无条件的死代码。

但是也有条件的死代码。那是在编译时无法识别的代码，只能在运行时检测到。例如，根据用户的喜好，可将软件配置为包括或排除某些功能，从而使某些代码段在特定情况下似乎已失效。那不是真正的死代码。

有一些特定的工具可以执行测试，解决依赖关系，删除条件无效代码并在运行时重新组合有用的代码以提高效率。这称为动态死代码消除。但是正如您所看到的，它超出了编译器的范围。

一个简单的例子：

int readValueFromPort(const unsigned int portNum);

int x = readValueFromPort(0x100); // just an example, nothing meaningful
if (x < 2)
{
    std::cout << "Hey! X < 2" << std::endl;
}
else
{
    std::cout << "X is too big!" << std::endl;
}

现在假定端口0x100设计为仅返回0或1。在那种情况下，编译器无法确定该else块将永远不会执行。

但是，在此基本示例中：

bool boolVal = /*anything boolean*/;

if (boolVal)
{
  // Do A
}
else if (!boolVal)
{
  // Do B
}
else
{
  // Do C
}

在这里，编译器可以计算出该else块是无效代码。因此，仅当编译器具有足够的数据来找出该死代码时，编译器才可以警告该死代码，并且编译器应该知道如何应用该数据，以便确定给定的块是否为死代码。

编辑

有时数据在编译时不可用：

// File a.cpp
bool boolMethod();

bool boolVal = boolMethod();

if (boolVal)
{
  // Do A
}
else
{
  // Do B
}

//............
// File b.cpp
bool boolMethod()
{
    return true;
}

在编译a.cpp时，编译器无法知道boolMethod总是返回true。

编译器将始终缺少一些上下文信息。例如，您可能知道，双精度值永远不会超过2，因为这是您从库中使用的数学函数的功能。编译器甚至看不到库中的代码，并且它永远无法知道所有数学函数的所有功能，也无法检测到所有奇怪而复杂的方法来实现它们。

编译器不一定会看到整个程序。我可以有一个调用共享库的程序，该库会回调我程序中未直接调用的函数。

因此，如果在运行时更改该库，则针对该库而死的函数可能会变为活动状态。

如果编译器可以准确地消除所有无效代码，则将其称为解释器。

考虑以下简单情况：

if (my_func()) {
  am_i_dead();
}

my_func() 可以包含任意代码，并且为了使编译器确定返回的是true还是false，它必须运行代码或执行与运行代码等效的操作。

编译器的思想是仅执行部分代码分析，从而简化了单独运行环境的工作。如果执行完整的分析，则不再是编译器。

如果您将编译器视为函数c()所在的地方c(source)=compiled code，而将运行环境视为r()所在的地方r(compiled code)=program output，那么要确定任何源代码的输出，您必须计算的值r(c(source code))。如果计算c()需要的价值的知识r(c())对任何输入，就不需要单独的r()和c()：你可以得到一个函数i()从c()这样i(source)=program output。

其他人则对暂停问题等发表了评论。这些通常适用于部分功能。但是，很难甚至不可能知道是否使用了整个类型（类/等）。

在.NET / Java / JavaScript和其他运行时驱动的环境中，没有任何停止类型通过反射加载。这在依赖项注入框架中很流行，面对反序列化或动态模块加载时，甚至更难以推理。

编译器无法知道是否会加载此类类型。它们的名称可能在运行时来自外部配置文件。

您可能想四处寻找树震动，这是尝试安全删除未使用的代码子图的工具的常用术语。

参加功能

void DoSomeAction(int actnumber) 
{
    switch(actnumber) 
    {
        case 1: Action1(); break;
        case 2: Action2(); break;
        case 3: Action3(); break;
    }
}

您能证明actnumber永远不会2如此Action2()吗？

我不同意暂停问题。我不会称此类代码为死，即使实际上它永远也不会到达。

相反，让我们考虑：

for (int N = 3;;N++)
  for (int A = 2; A < int.MaxValue; A++)
    for (int B = 2; B < int.MaxValue; B++)
    {
      int Square = Math.Pow(A, N) + Math.Pow(B, N);
      float Test = Math.Sqrt(Square);
      if (Test == Math.Trunc(Test))
        FermatWasWrong();
    }

private void FermatWasWrong()
{
  Press.Announce("Fermat was wrong!");
  Nobel.Claim();
}

（忽略类型和溢出错误）死代码？

看这个例子：

public boolean isEven(int i){

    if(i % 2 == 0)
        return true;
    if(i % 2 == 1)
        return false;
    return false;
}

编译器无法知道int只能是偶数或奇数。因此，编译器必须能够理解您代码的语义。应该如何实施？编译器无法确保永远不会执行最低的回报。因此，编译器无法检测到无效代码。