Merge pull request #4430 from MicrosoftDocs/main638126875866646577sync_temp

For protected CLA branch, push strategy should use PR and merge to target branch method to work around git push error

Author: learn-build-service-prod[bot]

docs/code-quality/c26441.md

@@ -1,60 +1,58 @@
 ---
 description: "Learn more about: Warning C26441 NO_UNNAMED_GUARDS"
 title: Warning C26441
-ms.date: 11/15/2017
+ms.date: 2/7/2023
 f1_keywords: ["C26441", "NO_UNNAMED_GUARDS"]
 helpviewer_keywords: ["C26441"]
-ms.assetid: f923c422-ed01-4644-b40b-93f15fc5bb93
 ---
 # Warning C26441
 
 > Guard objects must be named (cp.44)
 
-**C++ Core Guidelines**:
-[CP.44](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#cp44-remember-to-name-your-lock_guards-and-unique_locks): Remember to name your lock_guards and unique_locks
+## C++ Core Guidelines
 
-The standard library provides a few useful classes that help to control concurrent access to resources. Objects of such types lock exclusive access during their lifetime. Lifetime management implies that every lock object must be named. That is, it must have a clearly defined lifetime that spans through the period in which access operations are executed. So, failing to assign a lock object to a variable is a mistake that effectively disables the locking mechanism (because temporary variables are transient). This rule tries to catch simple cases of such unintended behavior.
+[CP.44](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cp44-remember-to-name-your-lock_guards-and-unique_locks): Remember to name your `lock_guard`s and `unique_lock`s
 
 ## Remarks
 
-- Only standard lock types are tracked: `std::scoped_lock`, `std::unique_lock`, and `std::lock_quard`.
+The standard library provides locks to help control concurrent access to resources during their lifetime. When you declare a lock object without a name, the compiler creates a temporary object that's immediately destructed rather than one that lives to the end of the enclosing scope. So, failure to assign a lock object to a variable is a mistake that effectively disables the locking mechanism (because temporary variables are transient). This rule catches simple cases of such unintended behavior.
 
-- Only simple calls to constructors are analyzed. More complex initializer expressions may lead to inaccurate results, but it's an unusual scenario.
+This diagnostic only analyzes the standard lock types `std::scoped_lock`, `std::unique_lock`, and `std::lock_guard`. Warning [C26444](c26444.md) covers other unnamed RAII types.
 
-- Locks passed as arguments to function calls or returned as results of function calls are ignored.
-
-- Locks created as temporaries but assigned to named references to extend their lifetime are ignored.
+The analyzer only analyzes simple calls to constructors. More complex initializer expressions may lead to inaccurate results in the form of missed warnings. Locks passed as arguments to function calls or returned as results of function calls are ignored because the analysis tool is unable to determine if those locks are deliberately trying to protect that function call or if they should be extended. To provide similar protection for types returned by a function call, annotate them with `[[nodiscard]]`. The analyzer ignores locks created as temporaries but assigned to named references to extend their lifetime.
 
 Code analysis name: `NO_UNNAMED_GUARDS`
 
 ## Example
 
-Missing scoped variable:
+In this example the name of the scoped lock is missing.
 
 ```cpp
-void print_diagnostic(gsl::string_span<> text)
+void print_diagnostic(std::string_view text)
 {
     auto stream = get_diagnostic_stream();
     if (stream)
     {
         std::lock_guard<std::mutex>{ diagnostic_mutex_ }; // C26441
         write_line(stream, text);
-        // ...
     }
 }
 ```
 
-Missing scoped variable, corrected:
+To fix the error, give a name to the lock, which extends its lifetime.
 
 ```cpp
-void print_diagnostic(gsl::string_span<> text)
+void print_diagnostic(std::string_view text)
 {
     auto stream = get_diagnostic_stream();
     if (stream)
     {
         std::lock_guard<std::mutex> lock{ diagnostic_mutex_ };
         write_line(stream, text);
-        // ...
     }
 }
 ```
+
+## See also
+
+[C26444](C26444.md)

docs/code-quality/c28213.md

@@ -1,55 +1,72 @@
 ---
 description: "Learn more about: Warning C28213"
 title: Warning C28213
-ms.date: 09/08/2022
+ms.date: 02/07/2023
 f1_keywords: ["C28213", "BAD_USEHEADER", "__WARNING_BAD_USEHEADER"]
 helpviewer_keywords: ["C28213"]
-ms.assetid: e141a12a-4c46-47eb-aa9d-a6444472cfaa
 ---
 # Warning C28213
 
 > The `_Use_decl_annotations_` annotation must be used to reference, without modification, a prior declaration.
 
 ## Remarks
 
-`_Use_decl_annotations_` tells the compiler to use the annotations from an earlier declaration of the function. If no earlier declaration can be found, or if the current declaration makes changes to the annotations, then this warning is emitted.
+`_Use_decl_annotations_` tells the compiler to use the annotations from an earlier declaration of the function. If it can't find an earlier declaration, or if the current declaration makes changes to the annotations, it emits this warning. `_Use_decl_annotations_` also lets you remove all other annotations from the definition, and uses the declaration annotations for analysis of the function.
 
-Code analysis name: BAD_USEHEADER
+This diagnostic is frequently a side effect of refactoring or fixing other warnings by adjusting the annotations on a function. To fix the issue, use the same annotations at the other locations. To determine the correct set of annotations, look at the behavior in the function definition. In most cases, this behavior is intentional and the annotations to the function should reflect it. For more information on SAL annotations, see [Using SAL Annotations to reduce code defects](using-sal-annotations-to-reduce-c-cpp-code-defects.md).
 
-## Example
+It's important for the annotations to match between the declarations and the definition of a function. When the analysis tools analyze the call site of the function, they use the declaration annotations. If the declaration and definition don't match, the static analysis tools may produce incorrect results. When you fix this warning, it's common for your changes to have cascading effects as the tool reanalyzes the source with updated information.
+
+If this diagnostic occurs because the analyzer couldn't find a previous declaration in the translation unit, the most likely cause is a missing `#include` directive. To resolve this issue when you intentionally don't include the header file, verify that the annotations in the declaration and definition match, and remove the `_Use_decl_annotations_` annotation. Be careful when you don't include a header file, as the two sets of annotations may get out of sync in the future.
+
+Code analysis name: `BAD_USEHEADER`
+
+## Examples
 
 The following code generates C28160. The `buffer` parameter annotation doesn't match between the two files.
 
 *From example.h:*
 
 ```cpp
-void example_func(_Out_writes_(n) char* buffer, int n);
+void addNullTerminate(_Out_writes_(n) char* buffer, int n);
 ```
 
 *From example.cpp:*
 
 ```cpp
 _Use_decl_annotations_
-void example_func(_Out_writes_z_(n) char* buffer, int n)
+void addNullTerminate(_Out_writes_z_(n) char* buffer, int n)
 {
     buffer[n] = '\0';
 }
 ```
 
-This issue can be fixed by either changing the annotation so they match at all locations, or by removing all annotations except `_Use_decl_annotations_` from the function definition. In this example, `_Out_writes_z_` appears to be correct so we'll move that to the function declaration in the header file. The following code resolves this warning:
+Examine the function definition to determine what the correct annotations should be. In this case, `_Out_writes_z_(n)` appears to be correct, so we move that annotation to the function declaration in the header file. This change resolves the issue because the annotations in the declaration and definition now match.
 
 *From example.h:*
 
 ```cpp
-void example_func(_Out_writes_z_(n) char* buffer, int n);
+void addNullTerminate(_Out_writes_z_(n) char* buffer, int n);
 ```
 
+Now we can remove the buffer annotation on the definition to simplify future maintenance (although this step is optional).
+
 *From example.cpp:*
 
 ```cpp
 _Use_decl_annotations_
-void example_func(_Out_writes_z_(n) char* buffer, int n)
+void addNullTerminate(char* buffer, int n)
 {
     buffer[n] = '\0';
 }
 ```
+
+In real world code, it's not usually as clear which annotation is correct. For more information and guidance, see [using SAL Annotations to reduce code defects](using-sal-annotations-to-reduce-c-cpp-code-defects.md).
+
+## See also
+
+[Rule sets for C++ code](./using-rule-sets-to-specify-the-cpp-rules-to-run.md)\
+[Using SAL Annotations to reduce code defects](using-sal-annotations-to-reduce-c-cpp-code-defects.md)\
+[C28252](C28252.md)\
+[C28253](C28253.md)\
+[C28301](C28301.md)

docs/code-quality/c6029.md

@@ -1,82 +1,92 @@
 ---
 description: "Learn more about: Warning C6029"
 title: Warning C6029
-ms.date: 10/04/2022
+ms.date: 2/07/2023
 f1_keywords: ["C6029", "USING_TAINTED_DATA", "__WARNING_USING_TAINTED_DATA"]
 helpviewer_keywords: ["C6029"]
-ms.assetid: 07f89261-1b77-4597-9f34-12ce5d569b60
 ---
 # Warning C6029
 
-> Possible buffer overrun in call to '*function*': use of unchecked value
+> Possible buffer overrun in call to '*function*'
 
-## Remarks
+Possible buffer overrun in called function due to an unchecked buffer length/size parameter.
 
-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.
+## Remarks
 
-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.
+This warning indicates that code passes an unchecked size to a function that takes a buffer and a size. The code doesn't verify that the data read from some external source is smaller than the buffer size. An attacker might intentionally specify a larger than expected value for the size, which can lead to a buffer overrun. 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.
 
 Code analysis name: `USING_TAINTED_DATA`
 
 ## Example
 
-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:
+The following code generates this warning when it calls the annotated function `std::fread` two times. The code uses the first call to determine the length of the data to read in later calls. After the first call, analysis marks `dataSize` as coming from an untrusted source. Therefore, when the code passes the untrusted value to the second `std::fread` call, the analyzer generates this warning. A malicious actor could modify the file and cause the call to `std::fread` to overflow the `buffer` array. In real world code, you should also handle error recovery based on the return value of `std::fread`. For simplicity, these examples intentionally leave out error recovery code.
 
 ```cpp
-#include "windows.h"
+void processData(FILE* file)
+{
+    const size_t MAX_BUFFER_SIZE = 100;
+    uint32_t buffer[MAX_BUFFER_SIZE]{};
+    uint8_t dataSize = 0;
+
+    // Read length data from the beginning of the file
+    fread(&dataSize, sizeof(uint8_t), 1, file);
+    // Read the rest of the data based on the dataSize
+    fread(buffer, sizeof(uint32_t), dataSize, file);
+}
+```
 
-bool f(HANDLE hFile)
+The fix for the issue depends on the nature of the data and the behavior of the annotated function that triggers the diagnostic. For more information, see the documentation for that function. A straightforward fix is to check the size before the second call to `std:fread`. In the next example, we throw an exception to terminate the function. Most real-world code would instead have an error recovery strategy that's specific to the scenario.
+
+```cpp
+void processData(FILE* file)
 {
-    char buff[MAX_PATH];
+    const size_t MAX_BUFFER_SIZE = 100;
+    uint32_t buffer[MAX_BUFFER_SIZE]{};
+    uint8_t dataSize = 0;
 
-    DWORD cbLen;
-    DWORD cbRead;
+    fread(&dataSize, sizeof(uint32_t), 1, file);
 
-    // Read the number of byte to read (cbLen).
-    if (!ReadFile (hFile, &cbLen, sizeof (cbLen), &cbRead, NULL))
-    {
-        return false;
-    }
-    // Read the bytes
-    if (!ReadFile (hFile, buff, cbLen, &cbRead, NULL))  // warning C6029
+    if (dataSize > MAX_BUFFER_SIZE)
     {
-        return false;
+        throw std::runtime_error("file data unexpected size");
     }
 
-    return true;
+    fread(buffer, sizeof(uint32_t), dataSize, file);
 }
 ```
 
-To correct this warning, check the buffer size as shown in the following code:
+In `std:fread` and similar functions, the code may need to read large amounts of data. To handle large data, you can allocate the size of the buffer dynamically after the size becomes known. Or, you can call `std:fread` multiple times as needed to read in the rest of the data. If you allocate the buffer dynamically, we recommend you put a limit on the size to avoid introducing an out-of-memory exploit for large values. We don't use this approach in our example because it's already bounded by the size of `uint8_t`.
 
 ```cpp
-bool f(HANDLE hFile)
+void processDataDynamic(FILE* file)
 {
-    char buff[MAX_PATH];
+    uint8_t dataSize = 0;
+    fread(&dataSize, sizeof(uint8_t), 1, file);
+    
+    // Vector with `dataSize` default initialized objects
+    std::vector<uint32_t> vecBuffer(dataSize);
 
-    DWORD cbLen;
-    DWORD cbRead;
+    fread(&vecBuffer[0], sizeof(uint32_t), dataSize, file);
+}
+void processDataMultiple(FILE* file)
+{
+    const size_t MAX_BUFFER_SIZE = 100;
+    uint32_t buffer[MAX_BUFFER_SIZE]{};
+    uint8_t dataSize = 0;
 
-    // Read the number of byte to read (cbLen).
-    if (!ReadFile (hFile, &cbLen, sizeof (cbLen), &cbRead, NULL))
-    {
-        return false;
-    }
-    // Ensure that there's enough space in the buffer to read that many bytes.
-    if (cbLen > sizeof(buff))
-    {
-        return false;
-    }
-    // Read the bytes
-    if (!ReadFile (hFile, buff, cbLen, &cbRead, NULL))  // warning C6029
+    fread(&dataSize, sizeof(uint32_t), 1, file);
+
+    while( dataSize > 0 )
     {
-        return false;
+        size_t readSize = dataSize > MAX_BUFFER_SIZE ? MAX_BUFFER_SIZE : dataSize;
+        readSize = fread(buffer, sizeof(uint32_t), readSize, file);
+        dataSize = dataSize - readSize;
+        // Process the data in `buffer`...
     }
-
-    return true;
 }
 ```
 
 ## See also
 
-- [Using SAL Annotations to reduce code defects](using-sal-annotations-to-reduce-c-cpp-code-defects.md)
+[Rule sets for C++ code](./using-rule-sets-to-specify-the-cpp-rules-to-run.md)\
+[Using SAL Annotations to reduce code defects](using-sal-annotations-to-reduce-c-cpp-code-defects.md)

docs/code-quality/c6064.md

@@ -1,16 +1,15 @@
 ---
 description: "Learn more about: Warning C6064"
 title: Warning C6064
-ms.date: 10/03/2022
+ms.date: 2/07/2023
 f1_keywords: ["C6064", "MISSING_INTEGER_ARGUMENT_TO_FORMAT_FUNCTION", "__WARNING_MISSING_INTEGER_ARGUMENT_TO_FORMAT_FUNCTION"]
 helpviewer_keywords: ["C6064"]
-ms.assetid: d8f126aa-b093-440e-820f-65b8e6cffaba
 ---
 # Warning C6064
 
 > Missing integer argument to '*function-name*' corresponding to conversion specifier '*number*'
 
-This warning indicates that not enough arguments are provided to match a format string and one of the missing arguments is an integer.
+This warning indicates that the code doesn't provide enough arguments to match a format string and one of the missing arguments is an integer.
 
 ## Remarks
 
@@ -20,13 +19,13 @@ Code analysis name: `MISSING_INTEGER_ARGUMENT_TO_FORMAT_FUNCTION`
 
 ## Example
 
-The following code generates this warning because an incorrect number of arguments were used in the call to `sprintf_s` and the missing argument was an integer. If the unsafe function `sprintf` was used instead of the safer variant `sprintf_s`, this code would likely cause a stack overflow instead of just an unexpected output:
+The following code generates this warning because it uses an incorrect number of arguments in the call to `sprintf_s` and the missing argument is an integer. If the unsafe function `sprintf` was used instead of the safer variant `sprintf_s`, this code would likely cause a stack overflow instead of just an unexpected output:
 
 ```cpp
 void f()
 {
     char buff[8];
-    char *string="Hello";
+    const char *string="Hello";
     sprintf_s(buff, sizeof(buff), "%s %d", string);  // Attempts to print "Hello "
     // followed by a number up to eleven characters long, depending on the garbage
     // found on the stack. Any number other than a single non-negative digit can't
@@ -35,17 +34,18 @@ void f()
 }
 ```
 
-To correct this warning, specify missing arguments as shown in the following code:
+To correct this warning, specify missing arguments or adjust the format string. In this example, we add the missing integer value.
 
 ```cpp
 void f()
 {
     char buff[8];
-    char *string = "Hello";
+    const char *string = "Hello";
     sprintf_s(buff, sizeof(buff), "%s %d", string, strlen(string));
 }
 ```
 
 ## See also
 
-[`sprintf_s`, `_sprintf_s_l`, `swprintf_s`, `_swprintf_s_l`](../c-runtime-library/reference/sprintf-s-sprintf-s-l-swprintf-s-swprintf-s-l.md)
+[`sprintf_s`, `_sprintf_s_l`, `swprintf_s`, `_swprintf_s_l`](../c-runtime-library/reference/sprintf-s-sprintf-s-l-swprintf-s-swprintf-s-l.md)\
+[C4473](../error-messages/compiler-warnings/c4473.md)