Skip to content

Commit da2c53c

Browse files
Merge pull request #4539 from MicrosoftDocs/main638191639759544158sync_temp
For protected CLA branch, push strategy should use PR and merge to target branch method to work around git push error
2 parents 26e0c76 + e4b23e5 commit da2c53c

File tree

1 file changed

+6
-16
lines changed

1 file changed

+6
-16
lines changed

docs/code-quality/c6001.md

Lines changed: 6 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,6 @@ title: Warning C6001
44
ms.date: 10/04/2022
55
f1_keywords: ["C6001", "USING_UNINIT_VAR", "__WARNING_USING_UNINIT_VAR"]
66
helpviewer_keywords: ["C6001"]
7-
ms.assetid: 55e779f1-7295-48f7-8ce1-b43898b36cd8
87
---
98
# Warning C6001
109

@@ -18,7 +17,7 @@ Code analysis name: `USING_UNINIT_VAR`
1817

1918
## Example
2019

21-
The following code generates this warning because variable `i` is only initialized if `b` is true; otherwise an uninitialized `i` is returned:
20+
The following code generates this warning because variable `i` is only initialized if `b` is true:
2221

2322
```cpp
2423
int f( bool b )
@@ -49,9 +48,7 @@ int f( bool b )
4948

5049
## Heuristics
5150

52-
Variables are also considered initialized when they're passed by reference to
53-
another function. Thus, the following example would also consider `i` to be
54-
initialized.
51+
The following example shows that passing a variable to a function by reference causes the compiler to assume that it's initialized:
5552

5653
```cpp
5754
void init( int& i );
@@ -66,18 +63,13 @@ int f( bool b )
6663
{
6764
i = 0;
6865
}
69-
return i; // i is assumed to be initialized by init(i)
66+
return i; // i is assumed to be initialized because it's passed by reference to init()
7067
}
7168
```
7269
73-
This is to support the pattern of passing a pointer to a variable into
74-
an initialization function.
70+
This supports the pattern of passing a pointer to a variable into an initialization function.
7571
76-
Since many functions expect pointers to point to initialized data already, this
77-
heuristic can lead to false negatives. [SAL annotations] such as `_In_` and
78-
`_Out_` can be used to more precisely describe a function's behavior. For
79-
example, in the following we call an external function that expects its argument
80-
to already be initialized and the warning is still generated.
72+
This heuristic can lead to false negatives because many functions expect pointers that point to initialized data. Use [SAL annotations](annotating-function-parameters-and-return-values.md), such as `_In_` and `_Out_`, to describe the function's behavior. The following example calls a function that expects its argument to be initialized, so a warning is generated:
8173
8274
```cpp
8375
void use( _In_ int& i );
@@ -86,7 +78,7 @@ int f( bool b )
8678
{
8779
int i;
8880
89-
use(i); // uninitialized variable warning because of _In_ annotation on use
81+
use(i); // uninitialized variable warning because of the _In_ annotation on use()
9082
9183
if ( b )
9284
{
@@ -96,8 +88,6 @@ int f( bool b )
9688
}
9789
```
9890

99-
[SAL annotations]: ./annotating-function-parameters-and-return-values.md
100-
10191
## See also
10292

10393
[Compiler Warning (level 1 and level 4) C4700](../error-messages/compiler-warnings/compiler-warning-level-1-and-level-4-c4700.md)

0 commit comments

Comments
 (0)