Merge pull request MicrosoftDocs#4429 from MugBergerFries/patch-1

Updated C6101

Author: denrea

docs/code-quality/c6101.md

@@ -1,14 +1,39 @@
 ---
 description: "Learn more about: C6101"
 title: C6101
-ms.date: 11/04/2016
+ms.date: 08/17/2022
 ms.topic: reference
-f1_keywords: ["C6101"]
+f1_keywords: ["C6101", "RETURN_UNINIT_VAR", "__WARNING_RETURN_UNINIT_VAR"]
 helpviewer_keywords: ["C6101"]
 ms.assetid: 8546367c-5de5-479a-a231-c15c0aa89ef1
 ---
-# C6101
+# Warning C6101
 
-> warning C6101: Returning uninitialized memory
+> Returning uninitialized memory '\**parameter-name*'. A successful path through the function does not set the named \_Out\_ parameter.
 
-A successful path through the function does not set the named `_Out_` parameter. This message is generated based on SAL annotations that indicate that the function in question always succeeds. A function that doesn't return a success/failure indication should set all of its `_Out_` parameters because the analyzer assumes that the `_Out_` parameter is uninitialized data before the function is called, and that the function will set the parameter so that it's no longer uninitialized. If the function does indicate success/failure, then the `_Out_` parameter doesn't have to be set in the case of failure, and you can detect and avoid the uninitialized location. In either case, the objective is to avoid the reading of an uninitialized location. If the function sometimes doesn't touch an `_Out_` parameter that's subsequently used, then the parameter should be initialized before the function call and be marked with the `_Inout_` annotation, or the more explicit `_Pre_null_` or `_Pre_satisfies_()` when appropriate. "Partial success" can be handled with the `_When_` annotation. For more information, see [Using SAL Annotations to Reduce C/C++ Code Defects](../code-quality/using-sal-annotations-to-reduce-c-cpp-code-defects.md).
+## Remarks
+
+This message is generated based on SAL annotations that indicate that the function in question always succeeds. A function that doesn't return a success/failure indication should set all of its `_Out_` parameters because the analyzer assumes that the `_Out_` parameter is uninitialized data before the function is called, and that the function will set the parameter so that it's no longer uninitialized. If, however, the function does indicate success/failure and failure occurs, then the `_Out_` parameter doesn't have to be set. You can then detect and avoid the uninitialized location. In either case, the objective is to avoid the reading of an uninitialized location. If the function sometimes doesn't touch an `_Out_` parameter that's later used, then the parameter should be initialized before the function call and be marked with the `_Inout_` annotation, or the more explicit `_Pre_null_` or `_Pre_satisfies_()` when appropriate. "Partial success" can be handled with the `_When_` annotation. For more information, see [Using SAL Annotations to Reduce C/C++ Code Defects](../code-quality/using-sal-annotations-to-reduce-c-cpp-code-defects.md).
+
+Code analysis name: RETURN_UNINIT_VAR
+
+## Example
+
+The following code generates this warning. This issue stems from the pointer p1 not being set despite having been annotated with `_Out_`.
+
+```cpp
+void example_func(_Out_ int *p1)
+{
+    return;
+}
+```
+
+To resolve the issue, you can set the value of the parameter. Or, if the value is always initialized before the function is called, change the SAL annotation to `_Inout_`. By setting the value of the parameter, the following code avoids the warning:
+
+```cpp
+void example_func(_Out_ int *p1)
+{
+    *p1 = 1;
+    return;
+}
+```