Updated C6101

Mirror of my public PR. Added an example. Added proper spacing between headers and code blocks, matched formatting to my other PRs

Author: MugBergerFries

docs/code-quality/c6101.md

@@ -9,6 +9,31 @@ ms.assetid: 8546367c-5de5-479a-a231-c15c0aa89ef1
 ---
 # C6101
 
-> warning C6101: Returning uninitialized memory
+**Warning C6101: Returning uninitialized memory**\
+Example output:
+> 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).
+## Description
+
+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).
+
+## Example
+
+The following code generates this warning. This is due to the pointer p1 not being set despite being 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;
+}
+```