edits

Author: TylerMSFT

docs/code-quality/c26831.md

@@ -1,17 +1,17 @@
 ---
 title: Warning C26831
 description: "Describes the Microsoft C/C++ code analysis warning C26831, its causes, and how to address it."
-ms.date: 03/06/2023
+ms.date: 03/20/2023
 f1_keywords: ["C26831", "ALLOCATION_POTENTIAL_OVERFLOW"]
 helpviewer_keywords: ["C26831"]
 ---
-# Warning C26831
+# Warning `C26831`
 
 > Allocation size might be the result of a numerical overflow
 
 ## Remarks
 
-Checks for an allocation whose size may be the result of a numerical overflow. This check is targeted to find the following code pattern:
+This warning reports that the size specified for an allocation may be the result of a numerical overflow. For example:
 
 ```cpp
 void *SmallAlloc(int);
@@ -23,29 +23,32 @@ void foo(int i, int j)
 }
 ```
 
-In case `i+j` overflows, `SmallAlloc` returns a buffer that is smaller than expected. As a result, future accesses to the buffer like `p[i]` are out of bounds. These code patterns can result in remote code execution vulnerabilities.
+If `i+j` overflows, `SmallAlloc` returns a buffer that is smaller than expected. That will likely lead to out of bounds attempts to access the buffer later on. This code pattern can result in remote code execution vulnerabilities.
 
-Common allocation functions like `new`, `malloc`, and `VirtualAlloc` are recognized. The check also tries to recognize custom allocator functions by case insensitive search for the `alloc` substring in the function name.
+The check applies to common allocation functions like `new`, `malloc`, and `VirtualAlloc`. The check also applies to custom allocator functions that have `alloc` (case insensitive) in the function name.
 
-Our analysis engine's numerical solver have some limitations reasoning about numerical overflows. As a result, this check uses some heuristics and sometimes fails to recognize that certain checks can prevent overflows.
-Usually, checking for a reasonable bound on the allocation should work. 
+This check sometimes fails to recognize that certain checks can prevent overflows because the check is conservative.
 
 This warning is available in Visual Studio 2022 version 17.7 and later versions.
 
 ## Example
 
-To fix the previous code example, make sure `i+j` can't overflow. For example:
+To fix the previous code example in which `i+j` might overflow, introduce a check to make sure it won't. For example:
 
 ```cpp
 void *SmallAlloc(int);
 
 void foo(int i, int j)
 {
     if (i < 0 || j < 0 )
+    {
         return;
-    
+    }
+
     if (i > 100 || j > 100)
+    {
         return;
+    }
 
     int* p = (int*)SmallAlloc(i + j);
     p[i] = 5;
@@ -54,5 +57,5 @@ void foo(int i, int j)
 
 ## See also
 
-[C26832](c26832.md)\
-[C26833](c26833.md)
+[`C26832`](c26832.md)\
+[`C26833`](c26833.md)

docs/code-quality/c26832.md

@@ -5,13 +5,13 @@ ms.date: 03/06/2023
 f1_keywords: ["C26832", "ALLOCATION_POTENTIAL_OVERFLOW_AFTER_CAST"]
 helpviewer_keywords: ["C26832"]
 ---
-# Warning C26832
+# Warning `C26832`
 
 > Allocation size is the result of a narrowing conversion that could result in overflow
 
 ## Remarks
 
-Checks for an allocation whose size may be the result of a numerical overflow. This check is targeted to find the following code pattern:
+This warning reports that the size specified for an allocation may be the result of a narrowing conversion that results in a numerical overflow. For example:
 
 ```cpp
 void* SmallAlloc(int);
@@ -25,17 +25,17 @@ void foo(unsigned short i, unsigned short j)
 }
 ```
 
-In `i + j`, `i` and `j` are promoted to integers and the result of the addition is stored into a temporary integer. This integer is implicitly casted to `unsigned short` before the value is stored to `size`. The result of this cast might overflow. So, `SmallAlloc` might end up returning a buffer smaller than expected. Future accesses like `p[i]` are out of bounds. These code patterns can result in remote code execution vulnerabilities.
+In the expression `i + j`, both `i` and `j` are promoted to integers, and the result of the addition is stored in a temporary integer. Then, the temporary integer is implicitly cast to an `unsigned short` before the value is stored in `size`. The cast to `unsigned short` might overflow, in which case `SmallAlloc` may return a smaller buffer than expected. That will likely lead to out of bounds attempts to access the buffer later on. This code pattern can result in remote code execution vulnerabilities
 
-Common allocation functions like `new`, `malloc`, and `VirtualAlloc` are recognized. The check also tries to recognize custom allocator functions by case insensitive search for the `alloc` substring in the function name.
+This check applies to common allocation functions like `new`, `malloc`, and `VirtualAlloc`. The check also applies to custom allocator functions that have `alloc` (case insensitive) in the function name.
 
-Our analysis engine's numerical solver have some limitations reasoning about numerical overflows. As a result, this check uses some heuristics and sometimes fails to recognize that certain checks can prevent overflows.
-Usually, checking for a reasonable bound on the allocation should work. 
+This check sometimes fails to recognize that certain checks can prevent overflows because the check is conservative.
 
 This warning is available in Visual Studio 2022 version 17.7 and later versions.
+
 ## Example
 
-To fix the previous code example, make sure `i+j` can't overflow. For example:
+To fix the previous code example in which `i+j` might overflow, introduce a check to make sure it won't. For example:
 
 ```cpp
 void *SmallAlloc(int);
@@ -54,5 +54,5 @@ void foo(unsigned short i, unsigned short j)
 
 ## See also
 
-[C26831](c26831.md)\
-[C26833](c26833.md)
+[`C26831`](c26831.md)\
+[`C26833`](c26833.md)

docs/code-quality/c26833.md

@@ -5,13 +5,13 @@ ms.date: 03/06/2023
 f1_keywords: ["C26833", "ALLOCATION_POTENTIAL_OVERFLOW_BEFORE_CHECK"]
 helpviewer_keywords: ["C26833"]
 ---
-# Warning C26833
+# Warning `C26833`
 
 > Allocation size might be the result of a numerical overflow before the bound check
 
 ## Remarks
 
-Checks for an allocation whose size may be the result of a numerical overflow. This check is targeted to find the following code pattern:
+This waraning reports that the size specified for an allocation may be the result of a numerical overflow. For example:
 
 ```cpp
 void* SmallAlloc(int);
@@ -21,20 +21,23 @@ void foo(unsigned i, unsigned j)
     unsigned size = i + j;
 
     if (size > 50)
+    {
         return;
+    }
 
     int* p = (int*)SmallAlloc(size + 5); // Warning: C26833
     p[j] = 5;
 }
 ```
 
-The code example above has a check `size > 50`. Unfortunately, this check is too late. In case `i + j` overflows, it produces a small value that passes the check. So, `SmallAlloc` allocates a buffer smaller than expected. Future accesses of the buffer like `p[i]` are out of bounds. These code patterns can result in remote code execution vulnerabilities.
-Common allocation functions like `new`, `malloc`, and `VirtualAlloc` are recognized. The check also tries to recognize custom allocator functions by case insensitive search for the `alloc` substring in the function name.
+The check for `size > 50` is too late. If `i + j` overflows, it produces a small value that will pass the check. Then, `SmallAlloc` will allocate a buffer smaller than expected. That will likely lead to out of bounds attempts to access the buffer later on. This code pattern can result in remote code execution vulnerabilities.
 
-Our analysis engine's numerical solver have some limitations reasoning about numerical overflows. As a result, this check uses some heuristics and sometimes fails to recognize that certain checks can prevent overflows.
-Usually, checking for a reasonable bound on the allocation should work. 
+This check applies to common allocation functions like `new`, `malloc`, and `VirtualAlloc`. The check also applies to custom allocator functions that have `alloc` (case insensitive) in the function name.
+
+This check sometimes fails to recognize that certain checks can prevent overflows because the check is conservative.
 
 This warning is available in Visual Studio 2022 version 17.7 and later versions.
+
 ## Example
 
 To fix the previous code example, make sure `i+j` cannot overflow. For example:
@@ -45,12 +48,16 @@ void* SmallAlloc(int);
 void foo(unsigned i, unsigned j)
 {
     if (i > 100 || j > 100)
+    {
         return;
+    }
 
     unsigned size = i + j;
 
     if (size > 50)
+    {
         return;
+    }
 
     int* p = (int*)SmallAlloc(size + 5);
     p[j] = 5;
@@ -59,5 +66,5 @@ void foo(unsigned i, unsigned j)
 
 ## See also
 
-[C26831](c26831.md)\
-[C26832](c26832.md)
+[`C26831`](c26831.md)\
+[`C26832`](c26832.md)

docs/code-quality/c26835.md

@@ -1,45 +1,45 @@
 ---
 title: Warning C26835
 description: "Describes the Microsoft C/C++ code analysis warning C26835, its causes, and how to address it."
-ms.date: 03/06/2023
+ms.date: 03/20/2023
 f1_keywords: ["C26835", "RTL_COMPARE_MEMORY_MISUSE"]
 helpviewer_keywords: ["C26835"]
 ---
-# Warning C26835
+# Warning `C26835`
 
 > `RtlCompareMemory` returns the number of matching bytes. Consider replacing this call with `RtlEqualMemory`
 
 ## Remarks
 
-When `RtlCompareMemory`'s return value is used in a boolean context, it evaluates to true when there is at least 1 byte that is equal before finding a difference. This behavior is often not intentional. Moreover, comparing the result of `RtlCompareMemory` to 0 evaluates to false if there is at least 1 matching byte. This behavior is different from functions with compare in their name like `strcmp` making the code harder to understand. To check for equality, consider using `RtlEqualMemory` instead.
+When `RtlCompareMemory`'s return value is treated as a boolean, it evaluates to true when there is at least 1 equal byte before finding a difference. Moreover, comparing the result of `RtlCompareMemory` to 0 evaluates to false if there is at least 1 matching byte. This behavior may be unexpected because it is different from other comparison functions such as `strcmp`, making the code harder to understand. To check for equality, consider using `RtlEqualMemory` instead.
 
 This warning is available in Visual Studio 2022 version 17.7 and later versions.
 
-## Examples
+## Example
 
 ```cpp
 int foo(const void* ptr)
 {
-	if (RtlCompareMemory("test", ptr, 5) == 0) // C26835
-	{
-		// ... 
-	}
+    if (RtlCompareMemory("test", ptr, 5) == 0) // C26835
+    {
+        // ... 
+    }
 }
 ```
 
-To fix the issue, verify if the original intention was to check for equality and replace the function call with `RtlEqualMemory`.
+To fix the issue, verify if the original intention was to check for equality and replace the function call with `RtlEqualMemory`:
 
 ```cpp
 int foo(const void* ptr)
 {
-	if (RtlEqualMemory("test", ptr, 5)) // C26835
-	{
-		// ... 
-	}
+    if (RtlEqualMemory("test", ptr, 5)) // C26835
+    {
+        // ... 
+    }
 }
 ```
 
 ## See also
 
-[RtlEqualMemory macro (wdm.h)](/windows-hardware/drivers/ddi/wdm/nf-wdm-rtlequalmemory.md)\
-[RtlCompareMemory function (wdm.h)](/windows-hardware/drivers/ddi/wdm/nf-wdm-rtlequalmemory.md)
+[`RtlEqualMemory` macro (`wdm.h`)](/windows-hardware/drivers/ddi/wdm/nf-wdm-rtlequalmemory.md)\
+[`RtlCompareMemory` function (`wdm.h`)](/windows-hardware/drivers/ddi/wdm/nf-wdm-rtlequalmemory.md)