Skip to content

Repo sync for protected CLA branch #4197

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Sep 29, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 22 additions & 18 deletions docs/code-quality/c6200.md
Original file line number Diff line number Diff line change
@@ -1,46 +1,50 @@
---
description: "Learn more about: C6200"
title: C6200
ms.date: 11/04/2016
ms.date: 08/16/2022
ms.topic: reference
f1_keywords: ["C6200"]
f1_keywords: ["C6200", "INDEX_EXCEEDS_MAX_NONSTACK", "__WARNING_INDEX_EXCEEDS_MAX_NONSTACK"]
helpviewer_keywords: ["C6200"]
ms.assetid: bbeb159b-4e97-4317-9a07-bb83cd03069a
---
# C6200
# Warning C6200

> warning C6200: index \<name> is out of valid index range \<min> to \<max> for non-stack buffer \<variable>
> Index '*index*' is out of valid index range '*min*' to '*max*' for non-stack buffer '*parameter-name*'

This warning indicates that an integer offset into the specified array exceeds the maximum bounds of that array. This defect might cause random behavior or crashes.
This warning indicates that an integer offset into the specified non-stack array exceeds the maximum bounds of that array, potentially causing random behavior and/or crashes.

## Remarks

One common cause of this defect is using the size of an array as an index into the array. Because C/C++ array indexing is zero-based, the maximum legal index into an array is one less than the number of array elements.

Code analysis name: INDEX_EXCEEDS_MAX_NONSTACK

## Example

The following code generates this warning because the **`for`** loop exceeds the index range:
The following code generates this warning. This issue stems from the **`for`** loop exceeding the index range, attempting to access index 14 (the 15th element) when index 13 (the 14th element) is the last:

```cpp
int buff[14]; // array of 0..13 elements
void f()
{
for (int i=0; i<=14;i++) // i exceeds the index
{
buff[i]= 0; // warning C6200
// code...
}
int* buff = new int[14]; // array of 0..13 elements
for (int i = 0; i <= 14; i++) // i exceeds the index
{
buff[i] = 0; // warning C6200
}
delete[] buff;
}
```

To correct both warnings, use correct array size as shown in the following code:

```cpp
int buff[14]; // array of 0..13 elements
void f()
{
for ( int i=0; i < 14; i++) // loop stops when i < 14
{
buff[i]= 0; // initialize buffer
// code...
}
int* buff = new int[14]; // array of 0..13 elements
for (int i = 0; i < 14; i++) // i == 13 on the final iteration
{
buff[i] = 0; // initialize buffer
}
delete[] buff;
}
```
48 changes: 25 additions & 23 deletions docs/code-quality/c6201.md
Original file line number Diff line number Diff line change
@@ -1,46 +1,48 @@
---
description: "Learn more about: C6201"
title: C6201
ms.date: 11/04/2016
description: "Learn more about: Warning C6201"
title: Warning C6201
ms.date: 09/28/2022
ms.topic: reference
f1_keywords: ["C6201"]
f1_keywords: ["C6201", "INDEX_EXCEEDS_MAX", "__WARNING_INDEX_EXCEEDS_MAX"]
helpviewer_keywords: ["C6201"]
ms.assetid: eefbbd77-007c-4f28-95f6-6de5ee6a27db
---
# C6201
# Warning C6201

> warning C6201: buffer overrun for \<variable>, which is possibly stack allocated: index \<name> is out of valid index range \<min> to \<max>
> Index '*index-name*' is out of valid index range '*minimum*' to '*maximum*' for possibly stack allocated buffer '*variable*'

This warning indicates that an integer offset into the specified stack array exceeds the maximum bounds of that array. This defect might cause random behavior or crashes.
This warning indicates that an integer offset into the specified stack array exceeds the maximum bounds of that array. It may potentially cause stack overflow errors, random behavior, or crashes.

## Remarks

One common cause of this defect is using an array's size as an index into the array. Because C/C++ array indexing is zero-based, the maximum legal index into an array is one less than the number of array elements.

Code analysis name: INDEX_EXCEEDS_MAX

## Example

The following code generates this warning because the array index is out of the valid range:
The following code generates warning C6201. The **`for`** loop condition exceeds the valid index range for `buff` when it sets `i` to 14, which is one element past the end:

```cpp
void f( )
void f()
{
int buff[25];
for (int i=0; i <= 25; i++) // i exceeds array bound
{
buff[i]=0; // initialize i
// code ...
}
int buff[14]; // array of 0..13 elements
for (int i = 0; i <= 14; i++) // i == 14 exceeds the bounds
{
buff[i] = 0; // initialize buffer
}
}
```

To correct both warnings, use the correct array size as shown in the following code:
To correct the warning, make sure the index stays in bounds. The following code shows the corrected loop condition:

```cpp
void f( )
void f()
{
int buff[25];
for (int i=0; i < 25; i++)
{
buff[i]=0; // initialize i
// code ...
}
int buff[14]; // array of 0..13 elements
for (int i = 0; i < 14; i++) // i == 13 on the final iteration
{
buff[i]= 0; // initialize buffer
}
}
```
53 changes: 22 additions & 31 deletions docs/code-quality/c6276.md
Original file line number Diff line number Diff line change
@@ -1,59 +1,50 @@
---
description: "Learn more about: C6276"
title: C6276
ms.date: 11/04/2016
ms.date: 09/28/2022
ms.topic: reference
f1_keywords: ["C6276"]
f1_keywords: ["C6276", "CHAR_TO_WCHAR_CAST", "__WARNING_CHAR_TO_WCHAR_CAST"]
helpviewer_keywords: ["C6276"]
ms.assetid: 88f288da-da81-4d32-ab0f-be9d01a2606a
---
# C6276
# Warning C6276

> warning C6276: Cast between semantically different string types: char* to wchar_t\*. Use of invalid string can lead to undefined behavior
> Cast between semantically different string types. Use of invalid string can lead to undefined behavior.

This warning indicates a potentially incorrect cast from an ANSI string (`char_t*`) to a UNICODE string (`wchar_t *`). Because UNICODE strings have a character size of 2 bytes, this cast might yield strings that are not correctly terminated. Using such strings with the wcs* library of functions could cause buffer overruns and access violations.
This warning indicates a potentially incorrect cast from a narrow character string (`char*`) to a wide character string (`wchar_t*`).

## Example

The following code generates this warning:
## Remarks

```cpp
#include <windows.h>
VOID f()
{
WCHAR szBuffer[8];
LPWSTR pSrc;
Because the Microsoft compiler implements wide strings with a character size of 2 bytes, casting from a narrow string might produce strings that aren't correctly terminated. If you use such strings with the `wcs*` functions in the runtime library, they could cause buffer overruns and access violations.

Code analysis name: CHAR_TO_WCHAR_CAST

pSrc = (LPWSTR)"a";
wcscpy(szBuffer, pSrc);
}
```
## Example

The following code corrects this warning by appending the letter L to represent the ASCII character as a wide character:
The following code generates warning C6276. It's caused by an improper cast of the narrow string "a" (2 bytes, one for the 'a' and one for the null terminator) to a wide string (a 2-byte wide character 'a' with no null terminator):

```cpp
#include <windows.h>

VOID f()
void f()
{
WCHAR szBuffer[8];
LPWSTR pSrc;

pSrc = L"a";
wcscpy(szBuffer, pSrc);
WCHAR szBuffer[8];
LPWSTR pSrc;
pSrc = (LPWSTR)"a";
wcscpy_s(szBuffer, pSrc);
}
```

The following code uses the safe string manipulation function, `wcscpy_s`, to correct this warning:
The following code corrects this warning. It removes the problem cast and adds an `L` prefix to the string to define it as a properly terminated wide character string:

```cpp
#include <windows.h>

VOID f()
void f()
{
WCHAR szBuffer[8];
LPWSTR pSrc;
pSrc = L"a";
wcscpy_s(szBuffer,8,pSrc);
WCHAR szBuffer[8];
LPWSTR pSrc;
pSrc = L"a";
wcscpy_s(szBuffer, pSrc);
}
```
18 changes: 12 additions & 6 deletions docs/code-quality/c6277.md
Original file line number Diff line number Diff line change
@@ -1,21 +1,27 @@
---
description: "Learn more about: C6277"
title: C6277
ms.date: 11/04/2016
ms.date: 09/28/2022
ms.topic: reference
f1_keywords: ["C6277"]
f1_keywords: ["C6277", "CREATEPROCESS_ESCAPE", "__WARNING_CREATEPROCESS_ESCAPE"]
helpviewer_keywords: ["C6277"]
ms.assetid: 2b41252a-68c2-4e92-b005-0458db5f4430
---
# C6277
# Warning C6277

> warning C6277: NULL application name with an unquoted path in call to \<function>: results in a security vulnerability if the path contains spaces
> NULL application name with an unquoted path in call to '*function-name*': results in a security vulnerability if the path contains spaces

This warning indicates that the application name parameter is null and there might be spaces in the executable path name. In this case, unless the executable name is "fully qualified," there is likely to be a security problem. A malicious user might insert a rogue executable with the same name earlier in the path. To correct this warning, you can specify the application name instead of passing null or if you do pass null for the application name, use quotation marks around the executable path.
This warning indicates that the application name parameter is null and that there might be spaces in the executable path name.

## Remarks

Unless the executable name is fully qualified, there's likely to be a security problem. A malicious user could insert a rogue executable with the same name earlier in the path. To correct this warning, you can specify the application name instead of passing null. Alternatively, if you do pass null for the application name, use quotation marks around the executable path.

Code analysis name: CREATEPROCESS_ESCAPE

## Example

The following sample code generates this warning because the application name parameter is null, and the executable path name has a space in it; there is a risk that a different executable could be run because of the way the function parses spaces. For more information, see [CreateProcess](/windows/desktop/api/processthreadsapi/nf-processthreadsapi-createprocessa).
The following sample code generates warning C6277. The warning is caused by the NULL application name and from the executable path name having a space. Due to how the function parses spaces, there's a risk that a different executable could be run. For more information, see [`CreateProcessA`](/windows/desktop/api/processthreadsapi/nf-processthreadsapi-createprocessa).

```cpp
#include <windows.h>
Expand Down
62 changes: 31 additions & 31 deletions docs/code-quality/c6308.md
Original file line number Diff line number Diff line change
@@ -1,68 +1,68 @@
---
title: C6308
title: Warning C6308
description: "Understand the causes of Microsoft C/C++ code analysis warning C6308, and learn how to fix them."
ms.date: 10/23/2020
ms.date: 09/28/2022
ms.topic: reference
f1_keywords: ["C6308"]
f1_keywords: ["C6308", "REALLOCLEAK", "__WARNING_REALLOCLEAK"]
helpviewer_keywords: ["C6308"]
ms.assetid: 1162cd96-9037-4576-9858-0c8361a12559
---
# C6308
# Warning C6308

> warning C6308: 'realloc' may return null pointer: assigning a null pointer to \<variable>, which is passed as an argument to 'realloc', will cause the original memory block to be leaked
> 'realloc' may return null pointer: assigning a null pointer to '*parameter-name*', which is passed as an argument to 'realloc', will cause the original memory block to be leaked

This warning indicates a memory leak that is the result of the incorrect use of a reallocation function. Heap reallocation functions do not free the passed buffer if reallocation is unsuccessful. To correct the defect, assign the result of the reallocation function to a temporary, and then replace the original pointer after successful reallocation.
## Remarks

Heap reallocation functions don't free the passed buffer if reallocation is unsuccessful, potentially resulting in a memory leak if not handled properly. To correct the issue, assign the result of the reallocation function to a temporary variable, and then replace the original pointer after successful reallocation.

Code analysis name: REALLOCLEAK

## Example

The following sample code generates this warning:
The following sample code generates warning C6308. This issue stems from the assignment of the return value from `realloc` to `x`. If `realloc` fails and returns a null pointer, then the original memory pointed to by `x` won't be freed:

```cpp
#include <malloc.h>
#include <windows.h>

void f( )
{
char *x;
x = (char *) malloc(10);
if (x != NULL)
{
x = (char *) realloc(x, 512);
// code...
free(x);
}
char *x = (char *) malloc(10);
if (x != NULL)
{
x = (char *) realloc(x, 512);
// code...
free(x);
}
}
```

To correct this warning, use the following code:
To resolve the issue, you can create a temporary variable to store the return value of `realloc`. This change allows you to free the previously allocated memory safely if `realloc` fails:

```cpp
#include <malloc.h>
#include <windows.h>

void f()
{
char *x, *tmp;

x = (char *) malloc(10);

if (x != NULL)
{
tmp = (char *) realloc(x,512);
if (tmp != NULL)
char *x = (char *) malloc(10);
if (x != NULL)
{
x = tmp;
char *tmp = (char *) realloc(x,512);
if (tmp != NULL)
{
x = tmp;
}
// code...
free(x);
}
// code...
free(x);
}
}
```

This warning might generate noise if there is a live alias to the buffer-to-be-reallocated at the time of the assignment of the result of the reallocation function.
This warning might generate noise if there's a live alias to the buffer-to-be-reallocated at the time of the assignment of the result of the reallocation function.

To avoid these kinds of problems altogether, use the mechanisms that are provided by the C++ Standard Template 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).
To avoid these kinds of issues altogether, you can use the mechanisms that are provided by the C++ Standard Template 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).

## See also

[C6014](../code-quality/c6014.md)
[Warning C6014](../code-quality/c6014.md)