我正在研究通过 C 编译来实现高级(类似 Lisp)语言的可能性(如果异常足够有用的话，也可能是 C++)；这是许多项目之前使用过的策略。当然，这会生成与您手写的任何代码不同的 C 代码，并且在某些方面可能会超过其复杂性。
现代 C 编译器在正常使用中非常可靠，但很难知道在异常压力下的边缘情况中可能潜伏着哪些错误，特别是如果您看到一些隐藏的“好吧，没有程序员会编写比 Y 大的 X”限制。
我认为这些事实的巧合可能会导致不快乐。
在主要编译器(例如 GCC、Microsoft C++、Clang)的合理最新版本中，是否存在任何已知的案例，或者是否有一个好方法来查找生成的代码遇到边缘情况错误/限制的案例？
最佳答案
这可能不是您正在寻找的答案，但几年前，我参与了一个项目，其中系统的某些部分是用某种高级语言编写的，可以很容易地构建状态机流程。这种语言生成 C 代码，然后进行编译。我们在这个项目中使用的编译器是 gcc(版本约为 2.95 - 不要引用我的话，但肯定是 3.0 之前的版本)。我们确实遇到了一些代码生成错误，但从我的内存来看，这更多是与使用不太流行的处理器有关[揭示哪个处理器可能会揭示一些我不应该透露的项目信息，所以我宁愿不要说那是什么，即使那是很久以前的事了]。
与我关系密切的一位同事正在调查其中一个代码生成错误，该错误存在于大约 20 万行的函数中，所有函数都是一个大型 switch 语句，switch 语句中的每个案例大约有 50-1000 行每个(其中有多层子 switch 语句)。
根据我的内存，代码崩溃是因为它产生了无效的操作或将某些内容存储在已被其他内容占用的寄存器中，因此一旦您击中正确的代码位，它就会因非法内存访问而失败- 这与代码的长度无关，因为我的同事最终设法将其减少到大约 30 行代码(在多次“让我们把它删掉，看看它是否仍然出错”之后)，几天后，我们有了一个带有修复程序的新版本编译器。很高兴知道您为编译器服务契约(Contract)支付的数千美元至少有时是值得的......
我的观点是，现代编译器可以容忍大量大型代码。还有“合规编译器必须至少支持”的最低限制。例如，我相信(再次凭内存)，编译器需要支持函数内 127 级嵌套语句(即 127 个 if、switch、while 和 do-while 的组合)。而且，从某个地方的讨论(这就是“编译器应该支持 127 级嵌套语句”的来源)，我们发现 MSVC 和 GCC 都支持更多(足以让我们放弃寻找它...... )
关于c++ - 通过 C/C++ 编译和编译器错误/限制，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16448259/