Merge pull request #5888 from TylerMSFT/warningfix

various UUF fixes

Author: JillGrant615

docs/build/adding-references-in-visual-cpp-projects.md

@@ -21,13 +21,13 @@ To consume a library that you have downloaded by using the **vcpkg** package man
 
 If your static library project gets built in the same solution:
 
-1. #include the header file(s) for the static library using quotation marks. In a typical solution, the path starts with `../<library project name>`. IntelliSense will help you find it.
+1. `#include` the header file(s) for the static library using quotation marks. In a typical solution, the path starts with `../<library project name>`. IntelliSense will help you find it.
 2. Add a reference to the static library project. Right-click on **References** under the application project node in **Solution Explorer** and choose **Add Reference**.
 
 If the static library isn't part of the solution:
 
 1. Right-click on the application project node in **Solution Explorer** and then choose **Properties**.
-2. In the **VC++ Directories** property page, add the path to the directory that contains the LIB file to **Library Paths**. Then, add the path to the library header file(s) to **Include Directories**.  
+2. In the **VC++ Directories** property page, add the path to the directory that contains the LIB file to **Library Directories**. Then, add the path to the library header file(s) to **Include Directories**.  
 3. In the **Linker > Input** property page, add the name of the LIB file to **Additional Dependencies**.
 
 ## Dynamic link libraries
@@ -161,5 +161,5 @@ The following properties exist on COM and .NET assembly references, and aren't m
 
 ## See also
 
-[C++ project property page reference](reference/property-pages-visual-cpp.md)<br>
+[C++ project property page reference](reference/property-pages-visual-cpp.md)\
 [Set C++ compiler and build properties in Visual Studio](working-with-project-properties.md)

docs/c-runtime-library/crt-debug-heap-details.md

@@ -102,14 +102,11 @@ typedef struct _CrtMemBlockHeader
 
 The `no_mans_land` buffers on either side of the user data area of the block are currently 4 bytes in size, and are filled with a known byte value used by the debug heap routines to verify that the limits of the user's memory block haven't been overwritten. The debug heap also fills new memory blocks with a known value. If you elect to keep freed blocks in the heap's linked list, these freed blocks are also filled with a known value. Currently, the actual byte values used are as follows:
 
-`no_mans_land` (0xFD)\
-The "no_mans_land" buffers on either side of the memory used by an application are currently filled with 0xFD.
-
-Freed blocks (0xDD)\
-The freed blocks kept unused in the debug heap's linked list when the `_CRTDBG_DELAY_FREE_MEM_DF` flag is set are currently filled with 0xDD.
-
-New objects (0xCD)\
-New objects are filled with 0xCD when they're allocated.
+|Code  |Description  |
+|---------|---------|
+|`no_mans_land` (0xFD) | The "no_mans_land" buffers on either side of the memory used by an application are currently filled with 0xFD. |
+|Freed blocks (0xDD) | The freed blocks kept unused in the debug heap's linked list when the `_CRTDBG_DELAY_FREE_MEM_DF` flag is set are currently filled with 0xDD. |
+|New objects (0xCD) | New objects are filled with 0xCD when they're allocated.|
 
 ## Types of blocks on the debug heap
 
@@ -170,7 +167,7 @@ All calls to heap functions such as `malloc`, `free`, `calloc`, `realloc`, `new`
 
 ### To use the debug heap
 
-- Link the debug build of your application with a debug version of the C runtime library.
+Link the debug build of your application with a debug version of the C runtime library.
 
 ### To change one or more `_crtDbgFlag` bit fields and create a new state for the flag
 
@@ -275,9 +272,9 @@ Knowing the source file name and line number of an assert or reporting macro is
 
 ### Unique allocation request numbers and `_crtBreakAlloc`
 
-There's a simple way to identify the specific heap allocation call that went bad. It takes advantage of the unique allocation request number associated with each block in the debug heap. When information about a block is reported by one of the dump functions, this allocation request number is enclosed in braces (for example, "{36}").
+There's a simple way to identify the specific heap allocation call that went bad. It takes advantage of the unique allocation request number associated with each block in the debug heap. When information about a block is reported by one of the dump functions, this allocation request number is enclosed in braces. For example, `{36}`.
 
-Once you know the allocation request number of an improperly allocated block, you can pass this number to [`_CrtSetBreakAlloc`](./reference/crtsetbreakalloc.md) to create a breakpoint. Execution will break just before allocating the block, and you can backtrack to determine what routine was responsible for the bad call. To avoid recompiling, you can accomplish the same thing in the debugger by setting `_crtBreakAlloc` to the allocation request number you're interested in.
+Once you know the allocation request number of an improperly allocated block, you can pass this number to [`_CrtSetBreakAlloc`](./reference/crtsetbreakalloc.md) to create a breakpoint. Execution will break just before allocating the block and you can backtrack to determine what routine was responsible for the bad call. To avoid recompiling, you can accomplish the same thing in the debugger by setting `_crtBreakAlloc` to the allocation request number you're interested in.
 
 ### Creating debug versions of your allocation routines
 

docs/error-messages/compiler-warnings/compiler-warning-c4430.md

@@ -1,15 +1,15 @@
 ---
 description: "Learn more about: Compiler Warning (level 1, error) C4430"
 title: "Compiler warning (level 1, error) C4430"
-ms.date: "1/25/2025"
+ms.date: 04/22/2025
 f1_keywords: ["C4430"]
 helpviewer_keywords: ["C4430"]
 ---
 # Compiler Warning (level 1, Error) C4430
 
 > missing type specifier - int assumed. Note: C++ does not support default-int
 
-This error might be generated due to compiler conformance work done for Visual Studio 2005: all declarations must explicitly specify the type; `int` is no longer assumed.
+This warning is issued when a type specifier is missing in a declaration. The compiler used to assume the type was `int` in this case. But due to compiler conformance work done for Visual Studio 2005, all declarations must explicitly specify the type.
 
 C4430 is always issued as an error. You can turn off this warning with the `#pragma warning` or `/wd`. For more information, see [`warning`](../../preprocessor/warning.md) or [`/w`, `/W0`, `/W1`, `/W2`, `/W3`, `/W4`, `/w1`, `/w2`, `/w3`, `/w4`, `/Wall`, `/wd`, `/we`, `/wo`, `/Wv`, `/WX` (Warning Level)](../../build/reference/compiler-option-warning-level.md).
 
@@ -21,7 +21,6 @@ The following sample generates C4430:
 // compile with: /c
 struct CMyClass {
    CUndeclared m_myClass;  // C4430
-   int m_myClass;
 };
 
 typedef struct {
@@ -31,21 +30,4 @@ typedef struct {
 } POINT;
 ```
 
-The following addresses C4430:
-
-```cpp
-// compile with: /c
-
-#include "CUndeclared.h" // for `CUndeclared`
-
-struct CMyClass {
-   CUndeclared m_myClass;
-   int m_myClass;
-};
-
-typedef struct {
-   int someFunction();
-   unsigned x;
-   unsigned y;
-} POINT;
-```
+To fix this code, you'd need to define the type `CUndeclared` and the function `someFunction` prior to their use.

docs/error-messages/compiler-warnings/compiler-warning-level-2-c4146.md

@@ -1,29 +1,28 @@
 ---
 description: "Learn more about: Compiler warning (level 2) C4146"
 title: "Compiler warning (level 2) C4146"
-ms.date: 08/30/2022
+ms.date: 04/22/2025
 f1_keywords: ["C4146"]
 helpviewer_keywords: ["C4146"]
 ---
 # Compiler warning (level 2) C4146
 
 > unary minus operator applied to unsigned type, result still unsigned
 
-Unsigned types can hold only non-negative values, so unary minus (negation) usually doesn't make sense when applied to an unsigned type. Both the operand and the result are non-negative.
+Unsigned types only hold non-negative values. So unary minus (negation) usually doesn't make sense when applied to an unsigned type. Both the operand and the result are non-negative.
 
 ## Remarks
 
-When you express a negative integer literal, the **`-`** in front of the value is parsed as a [unary negation](../../cpp/unary-plus-and-negation-operators-plus-and.md) operator. The compiler applies the operator after it parses the numeric value. If the numeric value fits in the range of an unsigned integer type, but not the corresponding signed integer type, the compiler interprets the value as unsigned. An unsigned value is unchanged by the unary negation operator.
+When you express a negative integer literal, the **`-`** in front of the value is parsed as a [unary negation](../../cpp/unary-plus-and-negation-operators-plus-and.md) operator. The compiler applies the operator after it parses the numeric value. If the numeric value fits in the range of an unsigned integer type, but not the corresponding signed integer type, the compiler interprets the value as unsigned.
 
-This warning often occurs when you try to express the minimum **`int`** value, -2147483648, or the minimum **`long long`** value, -9223372036854775808. These values can't be written as -2147483648 or -9223372036854775808ll, respectively. The reason is because the compiler processes the expression in two stages: first, it parses the numeric value, then it applies the negation operator. For example, when the compiler parses -2147483648, it follows these steps:
+This warning often occurs when you try to express the minimum **`int`** value, -2147483648, or the minimum **`long long`** value, -9223372036854775808. These values can't be written as -2147483648 or -9223372036854775808ll. The reason is because the compiler processes the expression in two stages: first, it parses the numeric value, then it applies the negation operator. For example, when the compiler parses -2147483648, it follows these steps:
 
 1. The number 2147483648 is evaluated. Because it's greater than the maximum **`int`** value of 2147483647, but still fits in an **`unsigned int`**, the type of 2147483648 is **`unsigned int`**.
-
 1. Unary minus is applied to the unsigned value, with an unsigned result, which also happens to be 2147483648.
 
 The unsigned type of the result can cause unexpected behavior. If the result is used in a comparison, then an unsigned comparison might be used, for example, when the other operand is an **`int`**.
 
-You can avoid C4146 by using `INT_MIN` or `LLONG_MIN` from *`<limits.h>`* or the C++ equivalent, *`<climits>`*. These values have signed types.
+You can avoid **C4146** by using `INT_MIN` or `LLONG_MIN` from *`<limits.h>`* or the C++ equivalent, *`<climits>`*. These values have signed types.
 
 The [`/sdl` (Enable Additional Security Checks)](../../build/reference/sdl-enable-additional-security-checks.md) compiler option elevates this warning to an error.
 

docs/error-messages/compiler-warnings/compiler-warning-level-4-c4100.md

@@ -1,26 +1,24 @@
 ---
 description: "Learn more about: Compiler Warning (level 4) C4100"
 title: "Compiler Warning (level 4) C4100"
-ms.date: "11/04/2016"
+ms.date: 04/22/2025
 f1_keywords: ["C4100"]
 helpviewer_keywords: ["C4100"]
-ms.assetid: 478ed97d-e502-49e4-9afb-ac2a6c61194b
 ---
 # Compiler Warning (level 4) C4100
 
-'identifier' : unreferenced formal parameter
+> 'identifier' : unreferenced formal parameter
 
 The formal parameter is not referenced in the body of the function. The unreferenced parameter is ignored.
 
-C4100 can also be issued when code calls a destructor on a otherwise unreferenced parameter of primitive type.  This is a limitation of the Microsoft C++ compiler.
+C4100 can also be issued when code calls a destructor on an otherwise unreferenced parameter of primitive type.
 
 The following sample generates C4100:
 
 ```cpp
 // C4100.cpp
 // compile with: /W4
-void func(int i) {   // C4100, delete the unreferenced parameter to
-                     //resolve the warning
+void func(int i) {   // C4100, delete the unreferenced parameter to resolve the warning
    // i;   // Or uncomment this line to add a reference
 }