Warning C6101

Returning uninitialized memory 'parameter-name'.

A successful path through the function doesn't set the _Out_ annotated parameter.

Remarks

The purpose of this warning is to avoid the use of uninitialized values by callers of the function. The analyzer assumes callers don't initialize any parameters annotated with _Out_ before the function call, and checks that the function initializes them. The analyzer doesn't emit this warning if the function returns a value that indicates it had an error or wasn't successful. To fix this issue, make sure to initialize the _Out_ parameter under all successful return paths. The error message contains the line numbers of an example path that doesn't initialize the parameter.

If the initialization behavior is by design, then incorrect or missing SAL annotations are a likely cause for the warning. You can typically resolve these cases in one of two ways: Either change _Out_ to a more appropriate annotation, or use the _Success_() annotation to help define the success/error states of the function. It's important for the static analysis tools to have correct annotations on the function when analyzing the call sites of the function.

Fix by changes to parameter annotations

If the parameter should already be in an initialized state and the function conditionally modifies it, then the _Inout_ annotation may be more appropriate. If no other high level annotation fits the intended behavior, you can use low level annotations such as _Pre_null_, _Pre_satisfies_(), and _Post_satisfies_() that provide extra flexibility and control over the expected state of the parameter. For more information on parameter annotations, see Annotating function parameters and return values.

Fix by defining successful return paths

The analyzer only emits this warning when the code doesn't initialize an _Out_ parameter in the success paths of the function. If there's no _Success_ annotation and no function return type annotation, then it considers all return paths successful. For more information on _Success_ and similar annotations, see Success/Failure annotations.

Code analysis name: RETURN_UNINIT_VAR

Example

The following code generates this warning. Because the function returns void, the analyzer considers all paths successful. In this case, the correct fix would probably be to adjust the logic of the if statement, but in real world code it's typically not as straightforward and the solution depends on the intended behavior of the function.

#include <sal.h>
void AlwaysInit(_Out_ int* output, int input) // : warning C6101: Returning uninitialized memory '*p'.: Lines: 2, 4, 9, 14, 2
{
  if( input > 0 )
  {
    *output = input;
    return;
  }
  else if( input < 0 )
  {
    *output = 0;
    return;
  }
  return; // Oops, input was 0
}

To make the solution more interesting, we assume that it isn't valid to initialize output when input is 0. One approach is to modify the function return value to a different type, such as bool. Then, add a _Success_ annotation to define the successful return paths.

_Success_(return == true)
bool InitNotZero(_Out_ int* output, int input)
{
  if( input > 0 )
  {
    *output = input;
    return true;
  }
  else if( input < 0 )
  {
    *output = 0;
    return true;
  }
  return false;
}

If this pattern is common in your codebase, you can add the annotation to the return type. Error codes such as HRESULT from the Windows SDK give you the behavior of the _Success_ annotation without needing to add it to each function. If you already use an annotated type as a return type and want to override the behavior, then add the annotation to the function, as shown in the previous example.

using SuccessWhenTrue = _Success_(return == true) bool;

SuccessWhenTrue InitNotZero(_Out_ int* output, int input)
{
  // ...
}

See also

Rule sets for C++ code
Using SAL Annotations to Reduce C/C++ Code Defects