Fix warnings.

Xazax-hun · Xazax-hun · commit c047f2482041 · 2023-03-06T17:01:35.000-08:00
diff --git a/docs/code-quality/c26831.md b/docs/code-quality/c26831.md
@@ -23,11 +23,11 @@ void foo(int i, int j)
 }
 ```
 
-In case `i+j` overflows, `SmallAlloc` will return a buffer that is smaller than expected. As a result, future accesses to the buffer like `p[i]` will be out of bounds. These code patterns can result in remote code execution vulnerabilities.
+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.
 
 Our analysis engine's numerical solver have some limitations reasoning about numerical overflows. As a result, this check is using some heuristics and can sometimes be a bit noisy.
 
-# Example
+## Example
 
 To fix the code example above, make sure `i+j` cannot overflow. For example:
 
diff --git a/docs/code-quality/c26832.md b/docs/code-quality/c26832.md
@@ -25,11 +25,11 @@ void foo(unsigned short i, unsigned short j)
 }
 ```
 
-In `i + j`, `i` and `j` will be promoted to integers and the result of the addition will be stored into a temporary integer. This integer will be implicitly casted to `unsigned short` before the value is stored to `size`. The result of this cast might overflow. Consequently, `SmallAlloc` might end up returning a buffer smaller than expected. Future accesses like `p[i]` will be out of bounds. These code patterns can result in remote code execution vulnerabilities.
+In `i + j`, `i` and `j` will be promoted to integers and the result of the addition will be 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.
 
 Our analysis engine's numerical solver have some limitations reasoning about numerical overflows. As a result, this check is using some heuristics and can sometimes be a bit noisy.
 
-# Example
+## Example
 
 To fix the code example above, make sure `i+j` cannot overflow. For example:
 
diff --git a/docs/code-quality/c26833.md b/docs/code-quality/c26833.md
@@ -28,11 +28,11 @@ void foo(unsigned i, unsigned j)
 }
 ```
 
-The code example above has a check `size > 50`. Unfortunately, this check is too late. `i + j` might overflow and produce a small value that passes the check. Consequently, `SmallAlloc` might allocate a buffer smaller than expected. Future accesses of the buffer like `p[i]` might be out of bounds. These code patterns can result in remote code execution vulnerabilities.
+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.
 
 Our analysis engine's numerical solver have some limitations reasoning about numerical overflows. As a result, this check is using some heuristics and can sometimes be a bit noisy.
 
-# Example
+## Example
 
 To fix the code example above, make sure `i+j` cannot overflow. For example:
 
diff --git a/docs/code-quality/c26835.md b/docs/code-quality/c26835.md
@@ -11,7 +11,7 @@ helpviewer_keywords: ["C26835"]
 
 ## Remarks
 
-When `RtlCompareMemory`'s return value is used in a boolean context (compared to 0 or converted to bool), it will evaluate to true whenever a single byte matches. This is often not intentional. To check for equality, consider using `RtlEqualMemory` instead.
+When `RtlCompareMemory`'s return value is used in a boolean context (compared to 0 or converted to bool), it evaluates to true whenever a single byte matches. This is often not intentional. To check for equality, consider using `RtlEqualMemory` instead.
 
 ## Examples
 

Original file line number	Diff line number	Diff line change
`@@ -23,11 +23,11 @@ void foo(int i, int j)`
`23`	`23`	`}`
`24`	`24`	```
`25`	`25`
`26`		-In case `i+j` overflows, `SmallAlloc` will return a buffer that is smaller than expected. As a result, future accesses to the buffer like `p[i]` will be out of bounds. These code patterns can result in remote code execution vulnerabilities.
	`26`	+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.
`27`	`27`
`28`	`28`	`Our analysis engine's numerical solver have some limitations reasoning about numerical overflows. As a result, this check is using some heuristics and can sometimes be a bit noisy.`
`29`	`29`
`30`		`-# Example`
	`30`	`+## Example`
`31`	`31`
`32`	`32`	To fix the code example above, make sure `i+j` cannot overflow. For example:
`33`	`33`
Original file line number	Diff line number	Diff line change
`@@ -25,11 +25,11 @@ void foo(unsigned short i, unsigned short j)`
`25`	`25`	`}`
`26`	`26`	```
`27`	`27`
`28`		-In `i + j`, `i` and `j` will be promoted to integers and the result of the addition will be stored into a temporary integer. This integer will be implicitly casted to `unsigned short` before the value is stored to `size`. The result of this cast might overflow. Consequently, `SmallAlloc` might end up returning a buffer smaller than expected. Future accesses like `p[i]` will be out of bounds. These code patterns can result in remote code execution vulnerabilities.
	`28`	+In `i + j`, `i` and `j` will be promoted to integers and the result of the addition will be 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.
`29`	`29`
`30`	`30`	`Our analysis engine's numerical solver have some limitations reasoning about numerical overflows. As a result, this check is using some heuristics and can sometimes be a bit noisy.`
`31`	`31`
`32`		`-# Example`
	`32`	`+## Example`
`33`	`33`
`34`	`34`	To fix the code example above, make sure `i+j` cannot overflow. For example:
`35`	`35`
Original file line number	Diff line number	Diff line change
`@@ -28,11 +28,11 @@ void foo(unsigned i, unsigned j)`
`28`	`28`	`}`
`29`	`29`	```
`30`	`30`
`31`		-The code example above has a check `size > 50`. Unfortunately, this check is too late. `i + j` might overflow and produce a small value that passes the check. Consequently, `SmallAlloc` might allocate a buffer smaller than expected. Future accesses of the buffer like `p[i]` might be out of bounds. These code patterns can result in remote code execution vulnerabilities.
	`31`	+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.
`32`	`32`
`33`	`33`	`Our analysis engine's numerical solver have some limitations reasoning about numerical overflows. As a result, this check is using some heuristics and can sometimes be a bit noisy.`
`34`	`34`
`35`		`-# Example`
	`35`	`+## Example`
`36`	`36`
`37`	`37`	To fix the code example above, make sure `i+j` cannot overflow. For example:
`38`	`38`