Question

看起来像SAL bug。代码：

    PAAFILEFILTER_PROTECTED_FILE curFile = NULL;

     try
        {
            status = GetProtectedFile(FileIdInfo, instanceContext, &curFile);
            if(!NT_SUCCESS(status))
            {
                TraceError("Can't GetProtectedFile with status: %!STATUS!\n", status);
                leave;
            }
         ...


    finally
    {
        if(NT_SUCCESS(status))
        {
            LogMessage(AAFILEFILTER_FILE_UNPROTECTED, NULL, NULL, NULL, 0, (PUCHAR)FileIdInfo, sizeof(AAFILE_ID_INFORMATION));
        }
        else
        {
            TraceProtectedFile(curFile);
        }
    }

代码analysys给了我C6102 - Using variable from failed function call

在第TraceProtectedFile(curFile)行;但TraceProtectedFile有原型

_In_opt_ PAAFILEFILTER_PROTECTED_FILE protectedFile

_In_opt_ 意味着"_In_opt_ is the same as _In_, except that the input parameter is allowed to be NULL and, therefore, the function should check for this." ..如果CA无法处理如此简单的事情，那么就不要理会:(

Answer 1

这看起来像构建错误处理的方式有问题，而不是_In_opt_参数。

如果leave与标准C ++异常处理混合在一起，会让SAL足够混乱，以至于它无法识别finally永远不会被命中，我不会感到惊讶。 leave不是标准C ++例外的一部分，而且是针对structured exception handling的MSVC特定的。

好处是，SAL的混乱暗示其他开发人员可能同样会因此类错误处理而感到惊讶。您应该考虑将GetProtectedFile调用移到try / finally之外，因为所有代码都假定curFile已成功初始化：

PAAFILEFILTER_PROTECTED_FILE curFile = NULL;

status = GetProtectedFile(FileIdInfo, instanceContext, &curFile);
if(!NT_SUCCESS(status))
{
    TraceError("Can't GetProtectedFile with status: %!STATUS!\n", status);
    return; // Return whatever is appropriate here
}

// The rest of your code can assume curFile initialized successfully

try
{  
    ...
}
finally
{
    if(NT_SUCCESS(status))
    {
        LogMessage(AAFILEFILTER_FILE_UNPROTECTED, NULL, NULL, NULL, 0, (PUCHAR)FileIdInfo, sizeof(AAFILE_ID_INFORMATION));
    }
    else
    {
        TraceProtectedFile(curFile);
    }
}

代码分析不了解_In_opt_参数注释？

1 个答案: