You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> warning C6001: using uninitialized memory \<variable>
12
+
> Using uninitialized memory '*variable*'.
13
13
14
-
This warning is reported when an uninitialized local variable is used before it is assigned a value. This could lead to unpredictable results. You should always initialize variables before use.
14
+
## Remarks
15
+
16
+
This warning is reported when an uninitialized local variable is used before it's assigned a value. This usage could lead to unpredictable results. You should always initialize variables before use.
This warning indicates that your code dereferences a potentially null pointer. If the pointer value is invalid, the result is undefined. To resolve the issue, validate the pointer before use.
15
17
18
+
Code analysis name: `DEREF_NULL_PTR`
19
+
16
20
## Example
17
21
18
22
The following code generates this warning because a call to `malloc` might return null if insufficient memory is available:
The careless use of `malloc` and `free` leads to memory leaks and exceptions. To minimize these kinds of leaks and exception problems altogether, avoid allocating raw memory yourself. Instead, use the mechanisms provided by the C++ Standard Library (STL). These include [shared_ptr](../standard-library/shared-ptr-class.md), [unique_ptr](../standard-library/unique-ptr-class.md), and [vector](../standard-library/vector.md). For more information, see [Smart Pointers](../cpp/smart-pointers-modern-cpp.md) and [C++ Standard Library](../standard-library/cpp-standard-library-reference.md).
66
+
The careless use of `malloc` and `free` leads to memory leaks and exceptions. To minimize these kinds of leaks and exception problems altogether, avoid allocating raw memory yourself. Instead, use the mechanisms provided by the C++ Standard Library (STL). These include [`shared_ptr`](../standard-library/shared-ptr-class.md), [`unique_ptr`](../standard-library/unique-ptr-class.md), and [`vector`](../standard-library/vector.md). For more information, see [Smart Pointers](../cpp/smart-pointers-modern-cpp.md) and [C++ Standard Library](../standard-library/cpp-standard-library-reference.md).
63
67
64
68
## See also
65
69
66
70
- [Using SAL Annotations to reduce code defects](using-sal-annotations-to-reduce-c-cpp-code-defects.md)
67
-
- [NULL](../c-runtime-library/null-crt.md)
71
+
- [`NULL`](../c-runtime-library/null-crt.md)
68
72
- [Indirection and Address-of Operators](../c-language/indirection-and-address-of-operators.md)
This warning indicates that the specified pointer points to allocated memory or some other allocated resource that hasn't been freed.
15
15
16
16
## Remarks
17
17
18
18
The analyzer checks for this condition only when the `_Analysis_mode_(_Analysis_local_leak_checks_)` SAL annotation is specified. By default, this annotation is specified for Windows kernel mode (driver) code. For more information about SAL annotations, see [Using SAL Annotations to Reduce C/C++ Code Defects](../code-quality/using-sal-annotations-to-reduce-c-cpp-code-defects.md).
19
19
20
+
This warning is reported for both memory and resource leaks when the resource is commonly *aliased* to another location. Memory is aliased when a pointer to the memory escapes the function by using an `_Out_` parameter annotation, global variable, or return value. This warning can be reported on function exit if the argument is annotated that its release is expected.
21
+
22
+
Code Analysis won't recognize the actual implementation of a memory allocator (involving address arithmetic) and won't recognize that memory is allocated (although many wrappers will be recognized). In this case, the analyzer doesn't recognize that the memory was allocated and issues this warning. To suppress the false positive, use a `#pragma warning(disable: 6014)` directive on the line that precedes the opening brace `{` of the function body.
23
+
24
+
Code analysis name: `MEMORY_LEAK`
25
+
20
26
## Examples
21
27
22
28
The following code generates warning C6014:
@@ -76,10 +82,6 @@ int main( )
76
82
}
77
83
```
78
84
79
-
This warning is reported for both memory and resource leaks when the resource is commonly *aliased* to another location. Memory is aliased when a pointer to the memory escapes the function by using an `_Out_` parameter annotation, global variable, or return value. This warning can be reported on function exit if the argument is annotated that its release is expected.
80
-
81
-
Code Analysis won't recognize the actual implementation of a memory allocator (involving address arithmetic) and won't recognize that memory is allocated (although many wrappers will be recognized). In this case, the analyzer doesn't recognize that the memory was allocated and issues this warning. To suppress the false positive, use a `#pragma` directive on the line that precedes the opening brace `{` of the function body.
82
-
83
85
To avoid these kinds of potential leaks altogether, use the mechanisms that are provided by the C++ Standard Library (STL). These include [`shared_ptr`](../standard-library/shared-ptr-class.md), [`unique_ptr`](../standard-library/unique-ptr-class.md), and containers such as [`vector`](../standard-library/vector.md). For more information, see [Smart pointers](../cpp/smart-pointers-modern-cpp.md) and [C++ Standard Library](../standard-library/cpp-standard-library-reference.md).
> warning C6029: possible buffer overrun in call to \<function>: use of unchecked value
12
+
> Possible buffer overrun in call to '*function*': use of unchecked value
13
13
14
-
This warning indicates that a function that takes a buffer and a size is being passed a unchecked size. The data read-in from some external source has not been verified to see whether it is smaller than the buffer size. An attacker might intentionally specify a much larger than expected value for the size, which will lead to a buffer overrun.
14
+
## Remarks
15
15
16
-
Generally, whenever you read data from an untrusted external source, make sure to verify it for validity. It is usually appropriate to verify the size to make sure it is in the expected range.
16
+
This warning indicates that a function that takes a buffer and a size is being passed an unchecked size. The data read-in from some external source hasn't been verified to see whether it's smaller than the buffer size. An attacker might intentionally specify a much larger than expected value for the size, which will lead to a buffer overrun.
17
+
18
+
Generally, whenever you read data from an untrusted external source, make sure to verify it for validity. It's appropriate to verify the size to make sure it's in the expected range.
19
+
20
+
Code analysis name: `USING_TAINTED_DATA`
17
21
18
22
## Example
19
23
20
-
The following code generates this warning by calling the annotated function [ReadFile](/windows/desktop/api/fileapi/nf-fileapi-readfile) two times. After the first call, the Post attribute property marks the second parameter value untrusted. Therefore, passing an untrusted value in the second call to `ReadFile` generates this warning as shown in the following code:
24
+
The following code generates this warning by calling the annotated function [`ReadFile`](/windows/desktop/api/fileapi/nf-fileapi-readfile) two times. After the first call, the Post attribute property marks the second parameter value untrusted. Therefore, passing an untrusted value in the second call to `ReadFile` generates this warning as shown in the following code:
> warning C6031: return value ignored: *called-function* could return unexpected value
12
+
> Return value ignored: '*called-function*' could return unexpected value
13
13
14
-
This warning indicates the caller doesn't check a function's return value for failure. Depending on which function is being called, this defect can lead to seemingly random program misbehavior. That includes crashes and data corruptions in error conditions or low-resource situations.
14
+
## Remarks
15
+
16
+
Warning C6031 indicates the caller doesn't check a function's return value for failure. Depending on which function is being called, this defect can lead to seemingly random program misbehavior. That includes crashes and data corruptions in error conditions or low-resource situations.
15
17
16
18
In general, it isn't safe to assume that calls to functions requiring disk, network, memory, or other resources will succeed. The caller should always check the return value and handle error cases appropriately. Also consider using the `_Must_inspect_result_` annotation, which checks that the value is examined in a useful way.
In cases where it is necessary to ignore the return value of a function, assign the returned value to `std::ignore`. Assigning to `std::ignore` clearly indicates developer intent and helps in future code maintenance.
90
+
In cases where it's necessary to ignore the return value of a function, assign the returned value to `std::ignore`. Assigning to `std::ignore` clearly indicates developer intent and helps in future code maintenance.
> warning C6053: call to \<function> may not zero-terminate string \<variable>
12
+
> Call to '*function*' may not zero-terminate string '*variable*'.
13
13
14
-
This warning indicates that the specified function has been called in such a way that the resulting string might not be zero-terminated. This defect might cause an exploitable buffer overrun or crash. This warning is also generated if an annotated function expects a null terminated string is passed a string that is not null terminated.
14
+
## Remarks
15
15
16
-
Most C standard library and Win32 string handling functions require and produce zero-terminated strings. A few 'counted string' functions (including `strncpy`, `wcsncpy`, `_mbsncpy`, `_snprintf`, and `snwprintf`) do not produce zero-terminated strings if they exactly fill their buffer. In this case, a subsequent call to a string function that expects a zero-terminated string will go beyond the end of the buffer looking for the zero. The program should make sure that the string ends with a zero. In general, you should pass a length to the 'counted string' function one smaller than the size of the buffer and then explicitly assign zero to the last character in the buffer.
16
+
This warning indicates that the specified function has been called in such a way that the resulting string might not be zero-terminated. This defect might cause an exploitable buffer overrun or crash. This warning is also generated if an annotated function expects a null-terminated string, but you pass a non-null-terminated string.
17
+
18
+
Most C standard library and Win32 string handling functions require and produce zero-terminated strings. A few 'counted string' functions (including `strncpy`, `wcsncpy`, `_mbsncpy`, `_snprintf`, and `snwprintf`) don't produce zero-terminated strings if they exactly fill their buffer. In this case, a subsequent call to a string function that expects a zero-terminated string will go beyond the end of the buffer looking for the zero. The program should make sure that the string ends with a zero. In general, you should pass a length to the 'counted string' function one smaller than the size of the buffer and then explicitly assign zero to the last character in the buffer.
19
+
20
+
Code analysis name: `MISSING_ZERO_TERMINATION1`
17
21
18
22
## Examples
19
23
@@ -74,4 +78,4 @@ You should note that this warning is sometimes reported on certain idioms guaran
74
78
## See also
75
79
76
80
- [Using SAL Annotations to reduce code defects](using-sal-annotations-to-reduce-c-cpp-code-defects.md)
> warning C6054: string \<variable> may not be zero-terminated
12
+
> String '*variable*' may not be zero-terminated.
13
13
14
14
## Remarks
15
15
16
16
This warning indicates that a function that requires a zero-terminated string was passed a non-zero terminated string. A function that expects a zero-terminated string could look for the zero beyond the end of the buffer. This defect might cause an exploitable buffer overrun error or crash. The program should make sure the string passed in ends with a zero.
> warning C6059: Incorrect length parameter in call to \<function>. Pass the number of remaining characters, not the buffer size of \<variable>
12
+
> Incorrect length parameter in call to '*function*'. Pass the number of remaining characters, not the buffer size of '*variable*'.
13
13
14
-
This warning indicates that a call to a string concatenation function is probably passing an incorrect value for the number of characters to concatenate. This defect might cause an exploitable buffer overrun or crash. A common cause of this defect is passing the buffer size, instead of the remaining number of characters in the buffer, to the string manipulation function.
14
+
## Remarks
15
+
16
+
This warning indicates that a call to a string concatenation function is probably passing an incorrect value for the number of characters to concatenate. This defect might cause an exploitable buffer overrun or crash. A common cause of this defect is passing the buffer size (instead of the remaining number of characters in the buffer) to the string manipulation function.
17
+
18
+
Code analysis name: `BAD_CONCATENATION`
15
19
16
20
## Example
17
21
18
-
The following code generates this warning:
22
+
The following code generates warning C6059:
19
23
20
24
```cpp
21
25
#include<string.h>
@@ -27,9 +31,9 @@ void f( )
27
31
char *szState ="Washington";
28
32
char *szCity="Redmond, ";
29
33
30
-
strncpy(szTarget,szCity, MAX);
34
+
strncpy(szTarget,szCity, MAX);
31
35
szTarget[MAX -1] = '\0';
32
-
strncat(szTarget, szState, MAX); //wrong size
36
+
strncat(szTarget, szState, MAX); //wrong size
33
37
// code ...
34
38
}
35
39
```
@@ -46,14 +50,14 @@ void f( )
46
50
char *szState ="Washington";
47
51
char *szCity="Redmond, ";
48
52
49
-
strncpy(szTarget,szCity, MAX);
53
+
strncpy(szTarget,szCity, MAX);
50
54
szTarget[MAX -1] = '\0';
51
55
strncat(szTarget, szState, MAX - strlen(szTarget)); // correct size
52
56
// code ...
53
57
}
54
58
```
55
59
56
-
To correct this warning using the safe string manipulation function, see the following code:
60
+
To correct this warning using the safe string manipulation functions `strncpy_s` and `strncat_s`, see the following code:
0 commit comments