编译器和解释器可以存在错误，我们（作为用户）可以采取什么措施来解决它们？[关闭]

如果编译器的工作实质上是将源代码转换为机器级代码，那么编译器中是否会出现故障，即错误的“翻译”？

解释器也是如此：有时会无法输出所需的内容吗？

我还没有听说过编译器/解释器中的任何错误，但是它们存在吗？

是

您倾向于在正在积极开发的语言中找到它们，而不是在相对成熟的语言中找到它们（因此不会经常看到很多变化）。这可能就是为什么大多数语言都在稳定的各个“阶段”发布的原因。夜间构建比发布候选者要稳定的可能性要小得多，发布候选者本身要比完全发布和积极使用的版本要稳定的可能性小。

幸运的是，这些语言中的大多数（尤其是开放源语言）都将具有可向其提交报告的公共错误跟踪系统。

以我自己的经验，我在Windows的Scala中遇到了一个相当模糊但严重的错误。我将调查结果提交给Bug跟踪器，此问题很快得到解决。在那种情况下，语言开发人员足够聪明，可以在错误日志输出中包含一个有用的注释，表明我实际上遇到的是编译器错误，并指出了在何处提交报告。

用外行的话来说：

所有程序都可能存在错误。

编译器是程序。

因此，编译器可能会出现错误。

即使在硬件中也可能存在错误；一个著名的例子是奔腾FDIV错误。毫无疑问，编译器可能包含错误。

编译器和解释器也是软件，因此它们无法摆脱其他软件的任何问题。

这是一个编译器的例子近期的MSVC 11（2012） ，和这里的一对，他们是如何测试的后端的文章。

当然，因为编译器是软件。

在2005年，我为一家大公司编写的一个非常关键的软件出现了一段代码故障。由于花费了公司数百万美元进行纠正，因此他们当然发起了大规模调查。

幸运的是（从我的角度来看），这个问题原来是Delphi中的一个编译器问题。在try finally块中，函数的返回值被破坏，并导致绝对随机的结果返回给调用者。这已被记录，并得到Borland的认可。

众所周知，.NET实际上有数百种不同的内存泄漏，特别是在其早期实现中。

我认为，没有没有错误的软件之类的东西。编译器也不例外。但是，与大多数商业软件相比，它们经过了更全面的测试，并且被聪明，关键，有争议的人们所使用，因此，从总体上看，他们的业绩记录非常好。

不仅是错误，还包括故意的恶意软件。

其中最著名的是Brian Kernighan对原始Unix C编译器实施的“登录”木马。http://cm.bell-labs.com/who/ken/trust.html文章对此有一些了解。

是的，当然像任何软件编译器都存在错误一样，例如，此处的gcc错误列表

是。

此外，不仅与编译器一起使用，还与Interpretors / debuggers和任何第三方软件工具一起使用。

我们目前正在使用某些第三方软件，并且遇到了一些问题。有时他们感谢我们发现并报告错误。:)

其中一些也有一些内存泄漏，从而导致崩溃。这里的重要问题是，如何确定第三方工具或编译器是否存在使您的应用程序正常运行的错误？

编译器是一种程序，它读取用一种语言（源语言）编写的程序，并将其翻译为另一种语言（目标语言）（主要是机器语言）的另一个等效程序。

在编译器的不同阶段中，逐行扫描源语言代码。有一个符号表，可跟踪在源语言代码中扫描过的所有关键字。

阶段1：词法分析器-读取源程序中的所有字符并形成令牌的逻辑分隔（int，char，float，if-else，for，while等）

阶段2：语法分析器-分析令牌流的结构。表达式的层次分析，包括后缀/前缀等（a = b + c * d）

阶段3：语义分析器-令牌的类型检查（整数到实数，浮点数等）以及许多类似操作符优先级的检查。

阶段4：中间代码生成器-a = b + c * de（temp1 = c * d，temp2 = temp1 + b，temp3 = temp2-e）

阶段5：代码优化-消除的各种分析（控制流，数据流，转换）
：冗余代码，常量传播，部分无效代码，公共子表达式，循环不变代码

阶段6：代码生成-生成目标代码（多数为汇编语言），将值放入寄存器

所有这些阶段只不过是编写良好的程序，而其中可能存在N个缺陷。

当然，编译器只是程序，其作者也是白痴:)。甚至语言规范也可能有错误。示例：c＃+ foreach + lambda。

或在Python中，解释器中的错误：编译ast会使解释器崩溃。

好吧，如果您想查看编译器/ interpeter中的错误，请查看php。有一个著名的整数溢出错误。第一个修复程序从开始if (size > INT_MAX) return NULL;。故事的延续。