在各个领域，功能安全领域对开发人员提出了新要求。功能上安全的代码必须包括防御性代码，以防御各种原因引起的意外事件。例如，由于编码错误或宇宙射线事件而导致的内存损坏可能导致执行根据代码逻辑“不可能”的代码路径。高级语言，特别是C和C ++，包含数量众多的功能，这些功能的行为不是代码所遵循的语言规范所规定的。这种不确定的行为可能导致意外的结果和潜在的灾难性后果，而这在功能安全的应用程序中是无法接受的。出于这些原因，标准要求应用防御性编码，可测试的编码，有可能整理足够的编码覆盖率，
代码还必须实现高级别的代码覆盖率，在某些领域（尤其是汽车领域），设计通常需要复杂的外部诊断，校准和开发工具。出现的问题是，防御性编码和外部数据访问等实践并不属于编译器认可的领域。例如，C和C ++都没有为内存损坏留出任何余地，因此，除非在没有这种损坏的情况下可以访问旨在防止内存损坏的代码，否则在对代码进行优化时可以将其忽略。因此，如果不“优化”防御性代码，则必须在语法和语义上都可以实现。
未定义行为的实例也会引起意外。很容易建议应避免使用它们，但通常很难识别它们。如果存在它们，就不能保证已编译的可执行代码的行为将符合开发人员的意图。对调试工具使用的数据的“后门”访问代表了该语言不允许的另一种情况，因此可能会带来意想不到的后果。
编译器优化可能对所有这些领域产生重大影响，因为它们都不属于编译器供应商的职责范围。优化可能会导致在与“不可行”相关联时，即在存在于无法通过任何可能的输入值进行测试和验证的路径上存在的情况下，显然消除了防御性代码。更令人震惊的是，在构建系统可执行文件时，很可能会消除在单元测试期间显示的防御代码。仅仅因为在单元测试期间已经实现了防御性代码的覆盖范围，因此并不能保证其已存在于完整的系统中。
在功能安全这个陌生的领域，编译器可能超出了其要素。这就是为什么目标代码验证（OCV）代表了对任何与故障相关的后果都有严重后果的系统的最佳实践，甚至对于只有最佳实践就足够好的任何系统都代表了最佳实践。
|
楼主
标题置顶
标题高亮
