V1073. Check the following code block after the 'if' statement. Consider checking for typos.

The analyzer found a possible error related to the fact that the code block ('{ .... }'), coming after the 'if' statement, does not apply to it.

Consider the first synthetic example:

if (a == 1) nop();              // <=
{
  nop2();
}

At first glance, it may seem that the block will be executed if the condition is true, but in fact, it is not. The block will always be executed, regardless of the condition. This may mislead the programmer.

Let's consider some other code examples that will trigger the analyzer:

if (a == 2) nop(); else nop2(); // <=
{
  nop3();
}

if (a == 3) nop(); 
else nop2();                    // <=
{
  nop3();
}

It is worth noting that such a pattern itself may not be an error, it may appear in the code. Therefore, the analyzer filters cases when the 'if' statement is written in a single line, and one of the following statements is executed in its body: 'return', 'throw', 'goto'. For example:

if (a == 4) return;             // ok
{
  nop();
}

if (a == 5) throw;              // ok
{
  nop();
}

....
label:
....
if (a == 6) goto label;         // ok
{
  nop();
}

Also, the analyzer will not issue a warning if the lines with the 'if' statement and the code block that is not associated with it are not contiguous:

if (a == 7) nop();
// this is a block for initializing MyClass fields
{
  ....
}

If you get such a warning, and it is false, you can tell the analyzer about it by adding an empty line between the 'if' and the block.

Also, the diagnostic will not issue a warning when the 'if' body contains an empty statement (';'). The diagnostic rule V529 is responsible for this.

This diagnostic is classified as:

CWE-483