使用SAL注释的Visual Studio社区代码分析的质量

Question

我希望这个问题不超出SO的范围; 如果是（对不起那种情况），请告诉我它属于哪里，我会尝试将它移到那里。

用于C / C ++中静态代码分析的SAL注释的概念对我来说似乎非常有用。 以MSDN上错误实现的wmemcpy为例：了解SAL ：

wchar_t * wmemcpy(
   _Out_writes_all_(count) wchar_t *dest,
   _In_reads_(count) const wchar_t *src,
   size_t count)
{
   size_t i;
   for (i = 0; i <= count; i++) { // BUG: off-by-one error
      dest[i] = src[i];
   }
   return dest;
}

MSDN说“代码分析工具可以通过单独分析这个功能来捕获错误” ，这看起来很棒，但问题是，当我在VS 2017社区中粘贴此代码时，没有关于此代码分析的警告，甚至没有启用所有分析警告。 （像C26481 Don't use pointer arithmetic. Use span instead (bounds.1).这样的其他警告C26481 Don't use pointer arithmetic. Use span instead (bounds.1).执行。）

另一个应该产生警告的例子（至少根据SAL的目的是什么（源注释语言）以及SAL 1和2之间的区别是什么？ ），但不是：

_Success_(return) bool GetASmallInt(_Out_range_(0, 10) int& an_int);

//main:
int result;
const auto ret = GetASmallInt(result);
std::cout << result;

一个不正确的警告案例：

struct MyStruct { int *a; };

void RetrieveMyStruct(_Out_ MyStruct *result) {
    result->a = new int(42);
}

//main:
MyStruct s;
RetrieveMyStruct(&s);
 // C26486 Don't pass a pointer that may be invalid to a function. Parameter 1 's.a' in call to 'RetrieveMyStruct' may be invalid (lifetime.1).
 //  Don't pass a pointer that may be invalid to a function. The parameter in a call may be invalid (lifetime.1).

result显然标有_Out_而不是_In_或_Inout_所以这个警告在这种情况下没有意义。

我的问题是：为什么Visual Studio的基于SAL的代码分析看起来很糟糕; 我错过了什么吗？ Visual Studio Professional或Enterprise在这方面可能更好吗？ 还是有一种工具可以做得更好吗？

如果它真的非常糟糕：这是一个已知的问题，是否有可能计划改进这种类型的分析？

相关： visual studio 2013静态代码分析 - 它有多可靠？

Answer 1

函数契约 ，其中SAL注释是一种轻量级实现， 可以在本地推断函数是否正在做正确的事情并且使用错误或相反。 没有它们，你只能在整个程序的背景下讨论bug的概念。 有了它们，正如文档所说，可以在本地说一个函数的行为是一个bug，你可以希望静态分析工具能找到它。

即使有这方面的帮助，机械地验证一段代码没有错误仍然是一个难题。 存在不同的技术，因为存在针对该问题的各种部分方法。 它们都有优点和缺点，它们都包含大量的启发式方法。 循环是使预测程序的所有行为变得困难的部分，这些工具的实现者可能选择不对极其简单的循环硬编码模式，因为这些模式很少在实践中起作用。

如果它真的非常糟糕：这是一个已知的问题，是否有可能计划改进这种类型的分析？

是的，研究人员几十年来一直在研究这个主题，并继续改进理论并将理论思想转化为实用工具。 作为用户，您可以选择：

• 如果您需要您的代码没有错误，例如因为它是针对安全关键的上下文，那么您已经拥有非常繁重的方法，基于V-cycle每个级别的密集测试，这种类型的静态分析已经可以帮助您以较少（但有些）的努力达到相同的置信水平。 对于此目标，您需要比SAL注释更具表现力的合同规范。 一个例子是ACSL for C.
• 如果你不愿意付出相当大的努力来确保代码没有高可信度的错误，你仍然可以利用这种静态分析，但在这种情况下，请考虑任何发现的奖励作为奖励。 注释，因为它们具有正式定义的含义，即使在不涉及静态分析器的手动代码检查的上下文中也可以用于指定责任。 SAL注释是为此用例明确设计的。