visual studio 2013 static code analysis - how reliable is it?

问题

i am trying explore static code analysis option in VS 2013. I have written very simple code below

int main()
{
    int a, b; //found unused variable 
    std::cout << "Hello world!";
    std::cin >> a;

    int* i = new int; // analysis didn't find this memory leak 
    //delete i;
    //i = NULL;
}

when I run code analysis on the above block, I expect it finds int* i = new int; and warns about memory leak, but it didn't find but find unused variable b.

So now I am in bit confusion, memory leak is a most common mistake in C/C++ & this tool couldn't find this. Now my question is can we rely on this analysis or not ?

Environment: Windows 7, VS ultimate 2013.

回答1:

This is not the kind of code problem that /analyze (aka PREfast) is designed to detect. There are other common tools for detecting straight-forward memory leaks like the CRT Debug Heap--see MSDN. Arguably, you should be using C++11 functionality like std::unique_ptr in the first place and never have to remember to call delete.

#include <memory>
int main()
{
    int a, b; //found unused variable 
    std::cout << "Hello world!";
    std::cin >> a;

    auto i = std::make_unique<int>()
}

What /analyze is intended to do is provide some of the 'additional warnings' you get from products like lint, but mostly to do inter-procedural buffer size validation via SAL annotations.

This is the kind of bug it finds:

void someFunction(char *buffer, size_t len)
{
    ...
}

void otherFunction()
{
    char buff[128];
    someFunction(buff, 256);
}

When you add the required SAL that communicates the relationship between the pointer and the size:

void someFunction(_Out_writes_(len) char *buffer, size_t len)

It's chains of assumptions that get violated and result in buffer overflows are really hard to find, not so much memory leaks.

Another useful function of /analyze is to validate variable-length printf arguments vs. the format string:

void printf_debug( _In_z_ _Printf_format_string_ const char* format, ... )
{
    ...
}


void otherFunction()
{
    unsigned long l;
    std::wstring str;
    std::string str2;

    ...

    printf_debug( "%i %s %d", i, str.c_str(), str2.c_str());
}

VS 2015 and VS 2017 now include a few of the warnings that used to be only in /analyze in VS 2013 or earlier like shadowed variables and basic printf validation (if you write your own printf-style functions, you should still use /analyze with _Printf_format_string_). /analyze continues to provide SAL-based buffer analysis that is not part of the standard compiler.

The /analyze PREFast technology can detect potential memory leaks in some cases (particularly with C++ exception safety), dereferencing of potentially null pointers, using uninitialized memory, etc. It also has a lot of extra rules for dealing with kernel-mode coding and writing drivers particularly tracking locks, IRQL levels, etc.

Prefast And SAL Annotations

For C#, /analyze is the FXCop tool which is a code-analysis tool plus a 'style enforcer' for .NET.

来源：https://stackoverflow.com/questions/42179745/visual-studio-2013-static-code-analysis-how-reliable-is-it