c++ - 项目中可能存在未定义行为以及是否添加功能的困境

Question

我有这样的困境。也许有人会考虑基于这个意见，但我相信这与许多项目相关，也可能有人会给出不基于意见的答案。

想象一下，我得到了一个大型 C++ 项目，它可以正常工作很多年(有些人可能会说，如果有 UB，这并不意味着什么，但拜托，这意味着一些东西)。

现在，想象两种情况:

• 代码中有(未定义的行为)UB，但它仍然像我提到的那样工作
• 没有UB

让我们来看第一个场景。

现在如果有 UB(以及它的许多实例)并且项目一直运行良好，我想最好不要碰项目。

但是如果我想给项目添加功能，该怎么办呢？

在这种情况下:

• 甚至添加新的 library项目会增加项目停止运作的风险
• 使用新编译器重新编译会增加项目停止运行的风险

那么，如果代码中有 UB，并且一直运行良好，如果要为其添加新功能怎么办？如果不增加风险，该项目将停止正常工作？

仅通过代码检查修复大型 C++ 项目中的所有 UB 是否现实？如果不是，我们直奔主题，添加新功能可能会破坏工作项目，因为到目前为止它一直运行良好(请参阅上面的两个要点)。

或者也许有人告诉管理层，因为这种情况，不向项目添加任何东西是最安全的。

我希望我把我的问题说清楚了。

我很确定这是常见的情况，人们在这种情况下如何处理？

Answer 1

我知道这种情况。旧的代码库，需要新功能，并且现在需要它们(补充说它在 8051 上运行，如果还不够的话，它只有大约 31 个字节没有 64K)。 问题是由于项目的时间限制，重构、构建完整的单元测试等等都不是一个选项 - 所以要么以任何可行的方式完成，要么不完成

当然，这一切都是从评估现有代码开始的，获取文档并理解它，程序中的功能是什么，程序中的接口(interface)是什么。如果不存在，则分析代码，直到您合理地弄清楚它的模块、它们的作用以及它们如何相互交互，并对其进行一些文档记录。

根据你的问题，你似乎担心编译器是否会产生“正确”的结果，现在“正确”意味着它重现了相同的代码，这些代码在很久以前就可以工作，并且可能经过测试(至少是集成测试)，并且在部署的地方可能仍然可以正常工作。

环顾代码库，看看您是否仍然拥有以某种方式验证的成功编译的目标文件。如有必要，请进行一些研究(在您工作的公司中，原始开发人员的计算机可能仍位于某个地方，并带有经过正确验证的编译的工件)。得到那些。

然后创建您的构建脚本，确保它不会触及任何现有的目标文件，除非被要求这样做。这样你就不会编译它们，只链接它们，从而避免来自源代码中潜在 UB 的潜在错误编译。向此构建脚本添加一些警告系统，以检测源与原始文件相比是否发生了更改，因此您最终不会得到错误的链接。

通过这些准备工作，您可以设置一个工作环境，在该环境中您可以逐步完成更改。

如果你需要接触一个源文件，显然你需要对其进行全面评估，如果可用的话使用一些静态分析工具(并且显然在编译时打开所有警告，这样你就可以看到编译器本身可能捕获的任何内容)。

取消项目

您也必须考虑这一点。我假设严格的时间限制不允许“正确”的解决方案。当然，您必须评估风险，如果风险太高，软件的正确操作就太关键了，作为了解风险的开发人员，您有责任向需要完成工作的任何人正确解释它们。出于安全考虑或公司声誉，无论如何，根本不做这个项目可能更好，但那些有权做出决定的人必须理解为什么。