{"id":31106,"date":"2022-09-20T15:00:33","date_gmt":"2022-09-20T15:00:33","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cppblog\/?p=31106"},"modified":"2022-09-20T12:21:56","modified_gmt":"2022-09-20T12:21:56","slug":"microsoft-cpp-code-analysis-warnings-with-key-events","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/microsoft-cpp-code-analysis-warnings-with-key-events\/","title":{"rendered":"Microsoft C++ Code Analysis Warnings with Key Events"},"content":{"rendered":"

Introduction<\/span>\u00a0<\/span><\/h2>\n

To make your C++ coding experience as safe as possible, the Microsoft C++ Code Analysis has added new checks and improved existing ones to help you prevent bugs before they find their way into your products. Some of the checks work harder than others, analyzing the code deeper by simulating runtime behavior. As such, they can find defects that are harder to find through syntactic checks alone or through data flow analysis.<\/span>\u00a0<\/span><\/p>\n

It is natural that developers find it harder to find the root causes for some of these more complex warnings. Imagine a warning where the effect of the bug is detected tens or hundreds of lines below the root cause of the bug, and the code against which the defect is reported looks completely legitimate. How would you be able to quickly find the root cause and fix it?<\/span>\u00a0<\/span><\/p>\n

In this blog post, we would like to reintroduce an existing Visual Studio feature that has been there to help with this challenge, and to highlight the big improvements we have made to the feature which will make it easier and more compelling to use.<\/span>\u00a0<\/span><\/p>\n

Challenges with Code Analysis Warning<\/span>\u00a0<\/span><\/h2>\n

Let\u2019s review the usual challenges we have when a static code analysis check tells us there is a defect in our code. It can be best demonstrated with some example code with a known defect. The following example is intentionally made convoluted enough to demonstrate the challenge of finding the root cause for warnings from a path-sensitive check.<\/span>\u00a0<\/span><\/p>\n

 1\u00a0\u00a0 #include <Windows.h>\u00a0\r\n\u00a02\u00a0\u00a0\u00a0\r\n\u00a03\u00a0\u00a0 int test();\u00a0\r\n\u00a04\u00a0\u00a0\u00a0\r\n\u00a05\u00a0\u00a0 void t1()\u00a0\r\n\u00a06\u00a0\u00a0 {\u00a0\r\n\u00a07\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 VARIANT v1;\u00a0\r\n\u00a08\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 VARIANT v2;\u00a0\r\n\u00a09\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 VARIANT v3{};\u00a0\r\n10\u00a0\u00a0\u00a0\r\n11\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 VARIANT* pv = &v3;\u00a0\r\n12\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 VARIANT* pvTmp = nullptr;\u00a0\r\n13\u00a0\u00a0\u00a0\r\n14\u00a0\u00a0\u00a0\u00a0\u00a0 VariantInit(&v1);\u00a0\r\n15\u00a0\u00a0\u00a0\r\n16\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 if (test() != 0)\u00a0\r\n17\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 pvTmp = &v1;\u00a0\r\n18\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 else\u00a0\r\n19\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 pvTmp = &v2;\u00a0\r\n20\u00a0\u00a0\u00a0\u00a0\r\n21\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 switch (test())\u00a0\r\n22\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 {\u00a0\r\n23\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case 1:\u00a0\r\n24\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 case 2:\u00a0\r\n25\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 pv = pvTmp;\u00a0\r\n26\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 break;\u00a0\r\n27\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 default:\u00a0\r\n28\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 pv = &v3;\u00a0\r\n29\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 break;\u00a0\r\n30\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 }\u00a0\r\n31\u00a0\u00a0\u00a0\r\n32\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 VariantClear(pv); \/\/ Warning C33001 here\u00a0\r\n33\u00a0\u00a0 }<\/pre>\n
Running code analysis on this code will give a few warnings. One of them will be this:<\/span>\u00a0<\/span><\/p>\n
test.cpp(32) : warning C33001: VARIANT 'pv' was cleared when it was uninitialized (expression 'pv').: Lines: 5, 7, 8, 9, 11, 12, 14, 16, 19, 21, 25, 26, 32<\/pre>\n
In summary, clearing a VARIANT<\/code> object that was not properly initialized can result in many random problems, including crashes, memory errors, etc. More information about this specific check can be found at <\/span>c33001 | Microsoft Docs<\/span><\/a>. But for this discussion, let\u2019s focus on the root cause of the defect \u2013 why does the check say we are clearing a VARIANT<\/code> object that is not initialized?<\/span>\u00a0<\/span><\/p>\n
The line of code to which the warning points us is completely legitimate: we must clear the VARIANT<\/code> object before we are done with it. Then what is the problem? It must be that somewhere along the code flow that reaches line 32, the VARIANT<\/code> object that pv<\/code> points to has not been initialized.<\/span>\u00a0<\/span><\/p>\n
Let\u2019s try to find out where the root cause is. First, we will need to find out which VARIANT<\/code> object pv<\/code> points to. Then follow the code flow to see why that object has never been initialized. To figure those out, we will need to trace back the code flow from where the defect is reported. Because it is likely dependent on the path that the check analyzed, we will use the line numbers provided in the warning. That seems doable. However, that doesn\u2019t seem to be the most efficient way. Imagine a similar bug is in an excessively big function. A similar warning may come with tens or hundreds of lines of code to trace back. Many of us would feel offended by such a warning, rather than helped.<\/span>\u00a0<\/span><\/p>\n
This blog post is not about finding root cause by tracking back source code manually like this. So, before going any further along this path, let\u2019s see if there is any help available.<\/span>\u00a0<\/span><\/p>\n
Code Analysis Warning with Key Events<\/span>\u00a0<\/span><\/h2>\n
It may not be well known, but selected warnings from some of MSVC’s C++ static analysis checks that have been there for long time always had additional information that helps with tracing back your code to identify the root causes. This additional information is called \u201cKey Events.\u201d A Key Event is associated with a step in the analysis code flow. It explains what has happened in that specific step. During analysis, these checks add Key Event candidates to the steps where important or interesting events occur, e.g., when a new buffer is created, etc. As a check finds a defect, it collects all relevant Key Events along the code flow that led to the defect and adds them to the warning. Some common events are also added as Key Events – e.g., when a relevant variable is initialized or updated, when code flow branches, etc.<\/span>\u00a0<\/span><\/p>\n
Here is an example of a warning with Key Events from one of those older checks as they are presented in the Error List. You could get these by clicking on the expansion triangle icon in the left-most column of the warning:<\/span>\u00a0<\/span><\/p>\n
 <\/p>\n
\"Image<\/a><\/p>\n
As you can see, these Key Events add rich information to the warning, making it very easy to follow the code and understand what is going on along the code flow of the analysis.<\/span>\u00a0<\/span><\/p>\n
Improvements to Key Events<\/span>\u00a0<\/span><\/h2>\n
We believe in the value of Key Events for our customers. So, we decided to remove the hinderances in making it available for more checks. We also made it a lot easier to use.<\/span>\u00a0<\/span><\/p>\n
To solve the first problem, we added equivalent support to our newer engine, allowing many newer checks to add Key Events to their warnings with little effort. This was done earlier, and new checks have been adding Key Events to their warnings. As of the release of Visual Studio 2022 version 17.4 Preview 2 we have augmented many checks with Key Events, including warnings for:<\/span>\u00a0<\/span><\/p>\n