SAL (源注释语言)的目的是什么? SAL 1和SAL 2有什么区别？
正如标题中所要求的：
SAL (源注释语言)的目的是什么? SAL 1和SAL 2有什么区别？
我理解这种用法的基本原理，这有助于突出传递给函数的每个变量的用途，以及用于静态代码分析的其他各种东西，但它实际上有多大的区别(忽略了项目中其他程序员对参数要求的日益清晰)？
如果我有以下原型：
_Success_(return == 1)
int TestFunction( _In_ int* pTest, _Inopt_ char* pOptional );这应该是“告诉”静态分析器，函数在成功操作时返回1，pTest是不能是nullptr的指针，pOptional是可能是也可能不是nullptr的指针。但是，静态分析器不能从函数定义本身获取这些信息吗？此外，它如何处理它所获得的信息，如成功标准？
此外，为什么SAL 1和SAL 2有区别，为什么微软决定改变它们命名宏的方式(即从__out到_Out_，从__success到_Success_?)
很抱歉，如果在MSDN上详细描述了这一点，但是我无法在StackOverflow上找到它或任何其他问题，并给出一个详细的答案，所以我想我会问，希望我的好奇心得到满足。
提前谢谢你的时间！
回答 1
Stack Overflow用户
发布于 2013-05-05 18:05:01
我在你的问题中读到了多个问题，希望我都读到了：
为什么使用SAL而不只是从源推断？
对于使用SAL显式告诉分析器有关参数行为等细节的问题，有多种答案。
- 虽然分析器可以从实现中推断出参数行为，但它往往无法区分实现的意图和意外。作为开发人员，如果您显式地声明了不同参数的预期用途，分析器既可以验证您编写的实现是否符合您的意图，也可以验证调用方是否正确地使用它。
- 这为静态分析器提供了关于在源代码无法分析时函数行为的信息，例如，在作为Visual的一部分提供的各种头文件中声明的函数、驱动程序工具包等。
- SAL允许仅从源代码中表达难以从源代码中推断出来的概念，例如驱动程序中的锁使用和IRQL需求。
- 这也有助于与回调函数保持一致。Windows headers描述的一些框架可能声明一组回调函数，因此Windows框架将调用在其他地方定义的回调函数(应用程序、驱动程序等)。因此，Windows从未看到被调用函数的源，回调函数定义也从未看到调用者。
Success 分析器从获得什么信息？
这与你所写的案例并没有什么关系。但是，在有输出参数的情况下(例如Out和where )，这意味着如果函数不成功，调用方就不能依赖输出注释。例如：
_Success_(return) bool GetASmallInt(_Out_range_(0, 10) int& an_int);如果GetASmallInt返回true，则an_int将介于0到10之间，包括在内。如果它返回false，则不存在这样的保证，而且该变量甚至可能没有被函数初始化。
SAL 1和SAL 2之间有什么区别，以及为什么将注释从__in _In_**?**重命名为
在SAL的最初定义中的一些角落案例(如__in)与C++没有很好地结合。新的语法从一些新的实现开始，以确保它符合C和C++语法的要求。
SAL 1和SAL 2的主要区别在于SAL 2能够表达许多SAL 1不能表达的概念，而SAL 2的定义更好，特别是关于C++，如上所述。
https://stackoverflow.com/questions/16265188
复制相似问题
腾讯云开发者
