New code analysis quick fixes for uninitialized memory (C6001) and use before init (C26494) warnings

eli fessler

eli

In the latest Preview release of Visual Studio 2019 version 16.1, we’ve added two quick fixes to the Code Analysis experience focused around uninitialized variable checks. These quick fixes are available via the Quick Actions (lightbulb) menu on relevant lines, accessed by hovering over the line or squiggle, or by pressing Ctrl+Period.

The first release of Visual Studio 2019 brought in-editor code analysis and various C++ productivity improvements, including a quick fix for the NULL to nullptr rule and others. In implementing further code analysis quick fixes, we are basing decisions on the following criteria: 1) the warning should have a low false positive rate; 2) the warning should be high-impact and have a potentially significant downside if not corrected; 3) the warning should have a relatively simple fix. Looking at the most feasible warnings, Preview 3 provides quick fixes for the following:

C6001: using uninitialized memory <variable>

Visual Studio reports warning C6001 when an uninitialized local variable is used before being assigned a value, which can lead to unpredictable results. This warning may be fixed by adding empty curly braces so that the variable/object is value-initialized (will be all zeros).

New Code Analysis quick fixes: C6001

This warning and corresponding quick fix are enabled by default in the Microsoft Native Minimum ruleset.

C26494: VAR_USE_BEFORE_INIT

This warning goes hand-in-hand with the previous one and is fixed in the same wayHowever, while warning C6001 is generated where the uninitialized variable is usedwarning C26494 shows up where the variable is declared.

New Code Analysis quick fixes: CC26494

Note that this warning and corresponding quick fix are not enabled in the default ruleset, but rather under the C++ Core Check Type Rules. To change rulesets in an MSBuild project, navigate to Property Pages > Code Analysis > General; for projects using CMake, add the "codeAnalysisRuleset" key into your CMakeSettings.json with the value set to the full path or the filename of a ruleset file.

Send us feedback 

Thank you to everyone who helps make Visual Studio a better experience for all. Your feedback is critical in ensuring we can deliver the best Code Analysis experience. We’d love for you to download Visual Studio 2019 16.1 Preview 3, give it a try, and let us know how it’s working for you in the comments below or via email. If you encounter problems or have suggestionsplease Report A Problem, or let us know via Visual Studio Developer Community. You can also find us on Twitter @VisualC. 

eli fessler
eli fessler

Follow eli   

9 comments

  • Avatar
    Mike Diack

    I will also submit this as a formal feedback item, but the auto code fixes it produced when I tried it were very “unnatural”/strange to look at.e.g.int a;
    char *pPtr;
    becomes
    int a{};
    char *pPtr{};Rather than the much more natural:
    int a = 0;
    char *pPtr = nullptr;Do others agree?

      • Avatar
        Mike Diack

        I have to say Eli, I strongly disagree with the C++ Core guys on this one. Blindly following their recommendations, IMHO, is not a great idea, and in this instance, drastically reduces readability “at a glance”.Not only that if this is a shared code base (with source that gets built via multiple compilers – e.g. in my case I use VS 2005, 2013 and 2019 for some of the same source – legacy OS support), then this adding of {} produces code that doesn’t build on anything earlier than VS 2013.For such a simple case as initialising a POD (e.g. an int, float, pointer), the {} “fix” then produces code that cant be compiled by VS 2012 and earlier! Surely for POD types, where a simple, readable, back compatible initialisation can be done, this is preferable?!?!?!

      • Avatar
        Mike Diack

        You might wish to follow up. I raised it as a feedback item and it’s now being treated as a bug. The code it generates is so “new” that it won’t even compile on VS 2012 and earlier for even the most trivial cases…

        • eli fessler
          eli fessler

          Mike,

          Sorry for the delayed reply. I agree, following standards without any further discussion or nuance isn’t ideal. 🙂 I just sent your feedback here to the feature team, and we’ll take a look at revisiting this and discuss how to make it a better experience. If you’d like to send me an email to chat about this further, with me or others on the team, please do reach out at eli­.fessler@mi­­cro­sof­t.c­om. Thanks for your candid feedback!

  • Avatar
    Istvan Fabian

    This kind of assignment looks absolutely horrible in a legacy codebase, however it fits very well in a mostly uptodate Modern C++ source.As a bare minimum, there should be an option to quickly select between the styles before VS makes the change.
    Ideally, I think that VS should check the surrounding code and fix the initializer according to the style found in the current function and/or translation unit. VS should already have similar information by the time it suggests the change, so this should be doable.

    • Avatar
      Mike Diack

      Hi Istvan – I totally agree. Which is why I raised this here and as feedback/a bug. Whats worth knowing all is that the code it generates is so “modern C++” centric, that it won’t even compile on any compiler earlier than VS 2013 (even just assigning a null pointer or setting an integer to 0 )- which as you say, is a serious pain for legacy code.
      Fortunately Microsoft are treating it as a bug. Eli has brushed off my criticism too lightly IMHO.

      • eli fessler
        eli fessler

        Hi Istvan and Mike,

        As I replied below, we’re looking into this further and will discuss to see if we want to revisit this to make it better. We want users to have a good experience whether working with modern or legacy code; however, do note that these quick fixes, based on the C++ Core Guidelines (to “help people to use modern C++ effectively”), are imeant to help users modernize code, and to make it safer and more consistent. Nonetheless, these comments are helpful, and we appreciate these types of conversations and feedback – thanks!

Leave a comment