[参考译文] 编译器/TM4C129CNCZAD：错误：编译器错误报告 MISRA 规则12.7

对于包含问题 C 代码 的源文件、请按照文章如何提交编译器测试用例中的说明进行操作。

谢谢、此致、

乔治

George Mock

恭敬地说、当我提供的代码片段足以帮助任何有兴趣修复编译器错误以重现的 TI 工程师时、您链接到的页面要求进行大量额外工作。  我去除了对标头(TI 库除外)和其他内容(我无论如何都不能向您发送)的依赖、并将其提炼为问题代码。  编译器版本发生这种情况的版本为18.1.1、但我无法确定它在以前的版本中没有发生、我只知道它在15.12.6上没有发生。  如果您需要更多信息、我很乐意提供这些信息、但我认为我发布的内容应该足以继续。

在大多数情况下、阅读文章所需的时间比阅读文章所要求的时间要长。  本文解决了有关保护代码的问题。  但这一点都不是主要问题。

重点是精度。  TI 发布了许多(100？ 200？) 软件包。  每个封装都有多个版本。  即使在一个特定的软件包中、同一头文件的多个变体也很常见、每个变体略有不同。  虽然编译器诊断通常仅指一个源代码行、但周围环境通常很重要。  提供一个如文章中所述的预处理源文件可以避免所有这些问题。  本文请求编译器所看到的编译选项。  最后、它会请求您提供的编译器版本。

关于单一报告，这些不同细节的相对重要性各不相同。  但是、在许多报告中、所有这些细节都很重要。  这就是为什么该条要求这样做的原因。  借助本文中要求的所有详细信息、您可以确信我们将重现您所看到的确切问题、原因与此完全相同。  这不是你想要的吗？

关于您的具体报告...  我搜索了我碰巧安装的几个软件包、基于这些软件包、将测试案例拼凑在一起、得到 MISRA 12.7诊断。  但我还发现这个诊断对表达式中每个操作数的符号非常敏感。  因为我不得不猜测几件事、所以我不能肯定看到 MISRA 12.7也是出于同样的原因。

因此、按照文章 如何提交编译器测试用例中的说明继续请求测试用例是有道理的。

关于保护您的代码，下面是另一个需要考虑的想法... 创建预处理的源文件后，您可以手动删除问题源代码行不需要的函数、类型等。  我承认这可能需要一些时间、而且可能不切实际。

谢谢、此致、

乔治

我完全明白了。 我可以理解、获取每一位信息更有可能导致测试案例的可重现性更高。 考虑这一点：您的客户通常在这里发帖、因为他们正在尝试做一些事情、并在道路上撞墙以完成这件事(无论是否由于错误)。 我相信报告错误是可以修复的、因此我尝试在我有时间的情况下完成这项工作、 但是、如果我不得不付出非常小的努力来报告一个我可以解决的错误、但我不太可能报告这个错误。

保持提交错误的激活能量相对较低以便您听到此类反馈和错误是否符合 TI 的最佳利益？

关于这个特定的错误、听起来您可以复制它。 如果您可以在错误跟踪系统中归档错误以修复它、我将不胜感激(因为这不是我可以直接做的事情)。 如果您需要我提供更多反馈、我很乐意尝试提供。 如果你绝对不能复制它、我将看到我是否可以留出一些时间来执行一些额外的步骤、但在这一点上、我想我宁愿使用我已经放入的 pragma、除了规则和处理错误。

如果您使用了我发布的代码、我相信您会遇到同样的情况。  除非我缺少某些内容(这是可能的)、否则这些行中没有任何签名(隐式或显式)、并且它们在15.12.6版本的编译器中没有生成此错误、但它们在18.1.1等更高版本中执行。 感谢您的帮助！