编译器和语言规范/语法是否相同？

Question

可以编写编译器，从中不能对输入语言的语法和含义进行反向工程。

即。你总能从编译器中获得语言的规范吗？

我们想说要编译？某种语言，但我不希望阅读编译器的人能够阅读和阅读了解??

我个人认为编译器和语言规范是同构的，但我从学术角度对这是否错误感兴趣。

Answer 1

我认为编译器总是会显示它编译的语言的规范（我知道这是超级手工波浪）。

然而，可能没有算法这样做（即它是不可判定的），因为，例如，该算法需要找出编译器将停止的程序。

Answer 2

假设您说他们只能访问二进制文件：

简短回答：如果一个人关心得不够，那就不行了。

答案很长：如果一个人如此倾向并且有很多空闲时间，总是有可能将编译器翻到字节级并完全映射它。从那里，你可以找出逻辑树，并重建语言。

这会很痛苦，但这与“我能制作一种阻止专用用户破解cd-key验证的算法”属于同一类别。

现在，如果你从未真正将编译器交给一个人（想象某种代理系统？），那么说用户必须花费很长时间来强制执行语言规范是合理的，如果他能够产生一些可以完全锻炼它的东西。

如果您暗示他们可以访问源代码：

没有。您可以对其进行模糊处理，但编译器仍然需要构建相同的逻辑树，无论读取多么困难。

可能有一些深奥的方法来做到这一点..如果您以某种加密的二进制形式单独提供语言树...并且没有提供编译器的源...并且您的用户不是无聊的NSA类型

Answer 3

不，他们不一样。但是编译器不可避免地理解输入语言的语法，并且（希望）非常精确地遵循语言规范。因此，理解编译器意味着理解这些。

当然，可能会严重模糊编译器源代码，以至于没有人会费心去阅读它并提取语法和语言规则。当然这也伤害了开发人员（祝你好运！）。

另外，如果我想了解一下语言的某些内容（不是关于它是如何实现的，而是如何在更抽象的层次上定义的话），那么阅读编译器的源代码将是我的最后一个选择 - 我会去看看规范或其他一些authorative source（官方文档等），因为即使编译器的代码是可以理解的，它也会更容易。

Answer 4

我的直觉是你可以通过检查编译器的输出来确定编译器的语义行为。但是如果没有文档或访问编译器源，您将无法获得实际语法。如果你有源这会变得微不足道，所以我假设你没有编译器的源代码，只是作为工具访问它。

Answer 5

通常，如果代码中存在关于语义的信息（并且在任何解释器或编译器中始终存在操作语义），则始终可以提取该信息。唯一的问题是这种逆向工程的复杂性。所以，你需要一个混淆的语言和一个模糊的编译器。

例如，看一下Malbolge“反编译器”。