共用方式為


6001 - Using uninitialized memory <variable>

An uninitialized local variable is used before a value is assigned to it. This could lead to unpredictable results. You should always initialize variables before use.

PREfast for Drivers reports this warning at the first point where it can definitively determine that the value is incorrect. However, it is often the case that the error could actually occur earlier in the trace but it was not possible to prove it at that point. When that is the case, PREfast for Drivers will also give the line number of the first possible instance of the error. In those cases, the text "See line <number> for an earlier location where this can occur." is appended to the message. Typically, a code change should occur at or before that line number, rather than at the point that 6001 is reported.

Example

The following code elicits this warning because variable i is only initialized if b is true; otherwise, an uninitialized i is returned:

int f( bool b )
{
   int i;
   if ( b )
   {
      i = 0;
   }
   return i; // i is uninitialized if b is false
}

To avoid this warning, initialize the variable as shown in the following code:

int f( bool b )
{
   int i= -1;

   if ( b )
   {
      i = 0;
   }
   return i;
}

Warning Details

This warning is somewhat prone to false-positive results, but it is retained in PREfast for Drivers because actual errors of this type can cause serious problems. False-positive results are especially common when a variable is initialized in a loop and PREfast for Drivers assumes the case in which the loop is never executed.

PREfast for Drivers reports this warning near the first line of the function in which the specified variable is used and the issue is detected. This warning can be reported on function exit if the header annotations for the argument indicate that the caller is supposed to verify that the variable is initialized, but the variable is not actually initialized.

PREfast for Drivers also reports this warning when "bullet-proofing code" or security code is not coded correctly. For example:

if (NULL != var) {
    status = myFunction(var);
}
return status;

In this situation, the status should be explicitly initialized or an else statement should be used to provide an alternate path. An ASSERT macro might be considered, but it is much better for the driver to fail the call then to create an exception.

 

 

Send comments about this topic to Microsoft

Build date: 5/3/2011