MicrosoftDocs · Rageking8 · Sep 25, 2025 · Sep 25, 2025
diff --git a/docs/build/arm64-exception-handling.md b/docs/build/arm64-exception-handling.md
@@ -1,6 +1,6 @@
 ---
 title: "ARM64 exception handling"
-description: Describes the exception handling conventions and data used by windows on ARM64.
+description: "Describes the exception handling conventions and data used by windows on ARM64."
 ms.date: 01/13/2023
 ---
 # ARM64 exception handling
@@ -287,7 +287,7 @@ The unwind codes are encoded according to the table below. All unwind codes are
 |--|--|
 | `alloc_s` | 000xxxxx: allocate small stack with size \< 512 (2^5 * 16). |
 | `save_r19r20_x` | 001zzzzz: save `<x19,x20>` pair at `[sp-#Z*8]!`, pre-indexed offset >= -248 |
-| `save_fplr` | 01zzzzzz: save `<x29,lr>` pair at `[sp+#Z*8]`,  offset \<= 504. |
+| `save_fplr` | 01zzzzzz: save `<x29,lr>` pair at `[sp+#Z*8]`, offset \<= 504. |
 | `save_fplr_x` | 10zzzzzz: save `<x29,lr>` pair at `[sp-(#Z+1)*8]!`, pre-indexed offset >= -512 |
 | `alloc_m` | 11000xxx'xxxxxxxx: allocate large stack with size \< 32K (2^11 * 16). |
 | `save_regp` | 110010xx'xxzzzzzz: save `x(19+#X)` pair at `[sp+#Z*8]`, offset \<= 504 |

diff --git a/docs/build/reference/guard-enable-control-flow-guard.md b/docs/build/reference/guard-enable-control-flow-guard.md
@@ -1,6 +1,6 @@
 ---
-description: "Learn more about: /guard (Enable Control Flow Guard)"
 title: "/guard (Enable Control Flow Guard)"
+description: "Learn more about: /guard (Enable Control Flow Guard)"
 ms.date: 2/24/2025
 f1_keywords: ["/guard", "VC.Project.VCCLCompilerTool.ControlFlowGuard"]
 ---
@@ -21,7 +21,7 @@ The **`/guard:cf`** option causes the compiler to analyze control flow for indir
 
 When the **`/guard:cf`** Control Flow Guard (CFG) option is specified, the compiler and linker insert extra runtime security checks to detect attempts to compromise your code. During compiling and linking, all indirect calls in your code are analyzed to find every location that the code can reach when it runs correctly. This information is stored in extra structures in the headers of your binaries. The compiler also injects a check before every indirect call in your code that ensures the target is one of the verified locations. If the check fails at runtime on a CFG-aware operating system, the operating system closes the program.
 
-A common attack on software takes advantage of bugs in handling extreme or unexpected inputs. Carefully crafted input to the application may overwrite a location that contains a pointer to executable code. This technique can be used to redirect control flow to code controlled by the attacker. The CFG runtime checks don't fix the data corruption bugs in your executable. They instead make it more difficult for an attacker to use them to execute arbitrary code. CFG is a mitigation tool that prevents calls to locations other than function entry points in your code. It's similar to how Data Execution Prevention (DEP),  [/GS](gs-buffer-security-check.md) stack checks, and [`/DYNAMICBASE`](dynamicbase-use-address-space-layout-randomization.md) and [/HIGHENTROPYVA](highentropyva-support-64-bit-aslr.md) address space layout randomization (ASLR) lower the chances that your code becomes an exploit vector.
+A common attack on software takes advantage of bugs in handling extreme or unexpected inputs. Carefully crafted input to the application may overwrite a location that contains a pointer to executable code. This technique can be used to redirect control flow to code controlled by the attacker. The CFG runtime checks don't fix the data corruption bugs in your executable. They instead make it more difficult for an attacker to use them to execute arbitrary code. CFG is a mitigation tool that prevents calls to locations other than function entry points in your code. It's similar to how Data Execution Prevention (DEP), [/GS](gs-buffer-security-check.md) stack checks, and [`/DYNAMICBASE`](dynamicbase-use-address-space-layout-randomization.md) and [/HIGHENTROPYVA](highentropyva-support-64-bit-aslr.md) address space layout randomization (ASLR) lower the chances that your code becomes an exploit vector.
 
 To use the CFG exploit mitigation technique, pass **`/guard:cf`** to the compiler and **`/GUARD:CF`** to the linker.
 

diff --git a/docs/build/reference/module-exportheader.md b/docs/build/reference/module-exportheader.md
@@ -19,7 +19,7 @@ Tells the compiler to create the header units specified by the input arguments.
 
 ### Arguments
 
-The argument to `/exportHeader` is a `/headerName` command-line option that specifies the name,  *`header-name`*, of the header file to export.  
+The argument to `/exportHeader` is a `/headerName` command-line option that specifies the name, *`header-name`*, of the header file to export.  
 
 ## Remarks
 

diff --git a/docs/build/reference/property-page-xml-files.md b/docs/build/reference/property-page-xml-files.md
@@ -128,7 +128,7 @@ A **`<Rule>`** element is the root node in the XML file. It can have many attrib
 
   - `Label=""` indicates that when the properties are written as `ItemDefinition` metadata, the label of the parent ItemDefinitionGroup will be empty (every MSBuild element can have a Label). Visual Studio 2017 and later use labeled groups to navigate the .vcxproj project file. The groups that contain most `Rule` properties have an empty string as a label.
 
-  - `HasConfigurationCondition="true"` tells the project system to affix a configuration condition to the value so that it takes effect only for the current project configuration (the condition could be affixed to the parent group or the value itself). For example,  open the property pages off the project node and set the value of the property **Treat Warnings As Error** under **Configuration Properties > C/C++ General** to "Yes". The following value is written to the project file. Notice the configuration condition attached to the parent ItemDefinitionGroup.
+  - `HasConfigurationCondition="true"` tells the project system to affix a configuration condition to the value so that it takes effect only for the current project configuration (the condition could be affixed to the parent group or the value itself). For example, open the property pages off the project node and set the value of the property **Treat Warnings As Error** under **Configuration Properties > C/C++ General** to "Yes". The following value is written to the project file. Notice the configuration condition attached to the parent ItemDefinitionGroup.
 
     ```xml
     <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">

diff --git a/docs/build/reference/translateinclude.md b/docs/build/reference/translateinclude.md
@@ -13,7 +13,7 @@ This switch instructs the compiler to treat `#include` as `import` for header fi
 
 When used with [`/scanDependencies`](scandependencies.md) or [`/sourceDependencies-directives`](sourcedependencies-directives.md), the compiler lists as imported header units in the generated dependency file those headers that are both included in the source and have a corresponding entry in a `header-units.json` file. This dependency info is used by the build system to generate compiled header unit `.ifc` files. Once the header units are built, they're treated by the compiler as an `import` instead of an `#include`.
 
-The `header-units.json` file is only consulted when `/translateInclude` is specified. For more information about the format and purpose of the `header-units.json` file,  see [`header-units.json`](header-unit-json-reference.md).
+The `header-units.json` file is only consulted when `/translateInclude` is specified. For more information about the format and purpose of the `header-units.json` file, see [`header-units.json`](header-unit-json-reference.md).
 
 If an `#include` file isn't listed in the `header-units.json` file, it's treated as a normal `#include`.
 

diff --git a/docs/c-language/generic-selection.md b/docs/c-language/generic-selection.md
@@ -1,7 +1,7 @@
 ---
 title: "Generic selection (C11)"
 description: "Describes the C11 _Generic keyword used in the Microsoft Visual C compiler"
-ms.date: "6/29/2021"
+ms.date: 6/29/2021
 helpviewer_keywords: ["_Generic keyword [C]"]
 ---
 
@@ -26,7 +26,7 @@ For example, the expression `_Generic(42, int: "integer", char: "character", def
 
 The first *`assignment-expression`* is called the controlling expression. The type of the controlling expression is determined at compile time and matched against the *`assoc-list`* to find which expression to evaluate and return. The controlling expression isn't evaluated. For example, `_Generic(intFunc(), int: "integer", default: "error");` doesn't result in a call at runtime to `intFunc`.
 
-When the type of the controlling expression is determined, `const`,  `volatile`, and `restrict` are removed before matching against *`assoc-list`*.
+When the type of the controlling expression is determined, `const`, `volatile`, and `restrict` are removed before matching against *`assoc-list`*.
 
 Entries in the `assoc-list` that aren't chosen aren't evaluated.
 

diff --git a/docs/c-runtime-library/cgets-cgetws.md b/docs/c-runtime-library/cgets-cgetws.md
@@ -1,21 +1,20 @@
 ---
-description: "Learn more about: _cgets, _cgetws"
 title: "_cgets, _cgetws"
-ms.date: "4/2/2020"
+description: "Learn more about: _cgets, _cgetws"
+ms.date: 4/2/2020
 api_name: ["_cgetws", "_cgets", "_o__cgets", "_o__cgetws"]
 api_location: ["msvcr100.dll", "msvcr110.dll", "msvcr80.dll", "msvcr120.dll", "msvcr90.dll", "msvcrt.dll", "msvcr110_clr0400.dll", "ucrtbase.dll", "api-ms-win-crt-conio-l1-1-0.dll"]
 api_type: ["DLLExport"]
 topic_type: ["apiref"]
 f1_keywords: ["cgetws", "_cgetws", "_cgets"]
 helpviewer_keywords: ["_cgetws function", "strings [C++], getting from console", "console, getting strings from", "_cgets function", "cgetws function", "cgets function"]
-ms.assetid: 4d5e134a-58c3-4f62-befd-5d235b0212f4
 ---
 # `_cgets`, `_cgetws`
 
 Gets a character string from the console. More secure versions of these functions are available; see [`_cgets_s`, `_cgetws_s`](./reference/cgets-s-cgetws-s.md).
 
 > [!IMPORTANT]
-> These functions are obsolete. Beginning in Visual Studio 2015, they are not available in the CRT. The secure versions of these functions,  _cgets_s and _cgetws_s, are still available. For information on these alternative functions, see [`_cgets_s`, `_cgetws_s`](./reference/cgets-s-cgetws-s.md).
+> These functions are obsolete. Beginning in Visual Studio 2015, they are not available in the CRT. The secure versions of these functions, _cgets_s and _cgetws_s, are still available. For information on these alternative functions, see [`_cgets_s`, `_cgetws_s`](./reference/cgets-s-cgetws-s.md).
 
 > [!IMPORTANT]
 > This API cannot be used in applications that execute in the Windows Runtime. For more information, see [CRT functions not supported in Universal Windows Platform apps](../cppcx/crt-functions-not-supported-in-universal-windows-platform-apps.md).

diff --git a/docs/c-runtime-library/gets-getws.md b/docs/c-runtime-library/gets-getws.md
@@ -1,7 +1,7 @@
 ---
-description: "Learn more about: gets, _getws"
 title: "gets, _getws"
-ms.date: "4/2/2020"
+description: "Learn more about: gets, _getws"
+ms.date: 4/2/2020
 api_name: ["_getws", "gets", "_o__getws", "_o_gets"]
 api_location: ["msvcr80.dll", "msvcr90.dll", "msvcr120.dll", "msvcr110.dll", "msvcr110_clr0400.dll", "msvcrt.dll", "msvcr100.dll", "api-ms-win-crt-stdio-l1-1-0.dll"]
 api_type: ["DLLExport"]
@@ -14,7 +14,7 @@ helpviewer_keywords: ["getws function", "getts function", "_getws function", "li
 Gets a line from the **`stdin`** stream. More secure versions of these functions are available; see [`gets_s`, `_getws_s`](./reference/gets-s-getws-s.md).
 
 > [!IMPORTANT]
-> These functions are obsolete. Beginning in Visual Studio 2015, they are not available in the CRT. The secure versions of these functions,  `gets_s` and `_getws_s`, are still available. For information on these alternative functions, see [`gets_s`, `_getws_s`](./reference/gets-s-getws-s.md).
+> These functions are obsolete. Beginning in Visual Studio 2015, they are not available in the CRT. The secure versions of these functions, `gets_s` and `_getws_s`, are still available. For information on these alternative functions, see [`gets_s`, `_getws_s`](./reference/gets-s-getws-s.md).
 
 > [!IMPORTANT]
 > This API cannot be used in applications that execute in the Windows Runtime. For more information, see [CRT functions not supported in Universal Windows Platform apps](../cppcx/crt-functions-not-supported-in-universal-windows-platform-apps.md).

diff --git a/docs/c-runtime-library/global-state.md b/docs/c-runtime-library/global-state.md
@@ -29,7 +29,7 @@ There are two ways to isolate your component's CRT state from an app's CRT state
 - Starting in Windows versions beginning with Windows 10 version 2004, dynamically link to the CRT but call the OS-mode exports (the functions that begin with _o_). To call the OS-mode exports, statically link as before, but ignore the static UCRT by using linker option `/NODEFAULTLIB:libucrt.lib` (release) or `/NODEFAULTLIB:libucrtd.lib` (debug). And add `ucrt.osmode.lib` to the linker input. See [`/NODEFAULTLIB` (Ignore Libraries)](../build/reference/nodefaultlib-ignore-libraries.md) for details.
 
 > [!NOTE]
-> In source code,  write `setlocale()`, not `_o_setlocale()`. When you link against `ucrt.osmode.lib`, the linker will automatically substitute the OS-specific version of the function. That is, `setlocale()` will be substituted with `_o_setlocale()`.
+> In source code, write `setlocale()`, not `_o_setlocale()`. When you link against `ucrt.osmode.lib`, the linker will automatically substitute the OS-specific version of the function. That is, `setlocale()` will be substituted with `_o_setlocale()`.
 
 Linking against `ucrt.osmode.lib` disables some UCRT calls that are only available in app mode. Attempting to call these functions will result in a link error.
 

diff --git a/docs/c-runtime-library/parameter-validation.md b/docs/c-runtime-library/parameter-validation.md
@@ -1,14 +1,13 @@
 ---
 title: "Parameter Validation"
 description: "A description of parameter validation in the Microsoft C runtime library."
-ms.date: "11/04/2016"
+ms.date: 11/04/2016
 ms.topic: "concept-article"
 helpviewer_keywords: ["parameters, validation"]
-ms.assetid: 019dd5f0-dc61-4d2e-b4e9-b66409ddf1f2
 ---
 # Parameter validation
 
-Most of the security-enhanced CRT functions, and many that aren't, validate their parameters for things like checking pointers for `NULL`,  that integers fall into a valid range, or that enumeration values are valid. If an invalid parameter is found, the invalid parameter handler is called.
+Most of the security-enhanced CRT functions, and many that aren't, validate their parameters for things like checking pointers for `NULL`, that integers fall into a valid range, or that enumeration values are valid. If an invalid parameter is found, the invalid parameter handler is called.
 
 ## Invalid parameter handler routine
 

diff --git a/docs/c-runtime-library/reference/assert-asserte-assert-expr-macros.md b/docs/c-runtime-library/reference/assert-asserte-assert-expr-macros.md
@@ -1,7 +1,7 @@
 ---
-description: "Learn more about: _ASSERT, _ASSERTE, _ASSERT_EXPR Macros"
 title: "_ASSERT, _ASSERTE, _ASSERT_EXPR Macros"
-ms.date: "11/04/2016"
+description: "Learn more about: _ASSERT, _ASSERTE, _ASSERT_EXPR Macros"
+ms.date: 11/04/2016
 api_location: ["msvcrt.dll", "msvcr80.dll", "msvcr90.dll", "msvcr100.dll", "msvcr100_clr0400.dll", "msvcr110.dll", "msvcr110_clr0400.dll", "msvcr120.dll", "msvcr120_clr0400.dll", "ucrtbase.dll"]
 api_type: ["DLLExport"]
 topic_type: ["apiref"]
@@ -33,7 +33,7 @@ A wide string to display as part of the report.
 
 The `_ASSERT_EXPR`, `_ASSERT` and `_ASSERTE` macros provide an application with a clean and simple mechanism for checking assumptions during the debugging process. They're flexible because they don't need to be enclosed in `#ifdef` statements to prevent them from being called in a retail build of an application. This flexibility is achieved by using the [`_DEBUG`](../debug.md) macro. `_ASSERT_EXPR`, `_ASSERT` and `_ASSERTE` are only available when `_DEBUG` is defined at compile time. When `_DEBUG` isn't defined, calls to these macros are removed during preprocessing.
 
-`_ASSERT_EXPR`, `_ASSERT` and `_ASSERTE` evaluate their *`booleanExpression`* argument and when the result is **`false`** (0), they print a diagnostic message and call [`_CrtDbgReportW`](crtdbgreport-crtdbgreportw.md) to generate a debug report. The `_ASSERT` macro prints a simple diagnostic message,  `_ASSERTE` includes a string representation of the failed expression in the message, and `_ASSERT_EXPR` includes the *`message`* string in the diagnostic message. These macros do nothing when *`booleanExpression`* evaluates to nonzero.
+`_ASSERT_EXPR`, `_ASSERT` and `_ASSERTE` evaluate their *`booleanExpression`* argument and when the result is **`false`** (0), they print a diagnostic message and call [`_CrtDbgReportW`](crtdbgreport-crtdbgreportw.md) to generate a debug report. The `_ASSERT` macro prints a simple diagnostic message, `_ASSERTE` includes a string representation of the failed expression in the message, and `_ASSERT_EXPR` includes the *`message`* string in the diagnostic message. These macros do nothing when *`booleanExpression`* evaluates to nonzero.
 
 `_ASSERT_EXPR`, `_ASSERT` and `_ASSERTE` invoke `_CrtDbgReportW`, which causes all output to be in wide characters. `_ASSERTE` properly prints Unicode characters in *`booleanExpression`* and `_ASSERT_EXPR` prints Unicode characters in *`message`*.
 

diff --git a/docs/c-runtime-library/reference/ctan-ctanf-ctanl.md b/docs/c-runtime-library/reference/ctan-ctanf-ctanl.md
@@ -1,14 +1,13 @@
 ---
 title: "ctan, ctanf, ctanl"
 description: "API reference for ctan, ctanf, and ctanl; which retrieve the tangent of a complex number."
-ms.date: "11/04/2016"
+ms.date: 11/04/2016
 api_name: ["ctan", "ctanf", "ctanl"]
 api_location: ["msvcrt.dll", "msvcr80.dll", "msvcr90.dll", "msvcr100.dll", "msvcr100_clr0400.dll", "msvcr110.dll", "msvcr110_clr0400.dll", "msvcr120.dll", "msvcr120_clr0400.dll", "ucrtbase.dll", "api-ms-win-crt-math-l1-1-0.dll"]
 api_type: ["DLLExport"]
 topic_type: ["apiref"]
 f1_keywords: ["ctan", "ctanf", "ctanl", "complex/ctan", "complex/ctanf", "complex/ctanl"]
 helpviewer_keywords: ["ctan function", "ctanf function", "ctanl function"]
-ms.assetid: d3cbd25c-1e93-4a6d-8154-da42921f7223
 ---
 # `ctan`, `ctanf`, `ctanl`
 
@@ -56,7 +55,7 @@ Because C++ allows overloading, you can call overloads of **`ctan`** that take a
 
 | Routine | C header | C++ header |
 |---|---|---|
-| **`ctan`**,  **`ctanf`**, **`ctanl`** | \<complex.h> | \<ccomplex> |
+| **`ctan`**, **`ctanf`**, **`ctanl`** | \<complex.h> | \<ccomplex> |
 
 For more compatibility information, see [Compatibility](../compatibility.md).
 

diff --git a/docs/c-runtime-library/reference/exit-exit-exit.md b/docs/c-runtime-library/reference/exit-exit-exit.md
@@ -1,7 +1,7 @@
 ---
-description: "Learn more about: exit, _Exit, _exit"
 title: "exit, _Exit, _exit"
-ms.date: "4/2/2020"
+description: "Learn more about: exit, _Exit, _exit"
+ms.date: 4/2/2020
 api_name: ["_exit", "exit", "_o__exit", "_o_exit"]
 api_location: ["msvcrt.dll", "msvcr80.dll", "msvcr90.dll", "msvcr100.dll", "msvcr100_clr0400.dll", "msvcr110.dll", "msvcr110_clr0400.dll", "msvcr120.dll", "msvcr120_clr0400.dll", "ucrtbase.dll", "api-ms-win-crt-runtime-l1-1-0.dll"]
 api_type: ["DLLExport"]
@@ -52,7 +52,7 @@ The **`exit`**, **`_Exit`**, **`_exit`**, **`quick_exit`**, **`_cexit`**, and **
 | **`_cexit`** | Performs complete C library termination procedures and returns to the caller. Doesn't terminate the process. |
 | **`_c_exit`** | Performs minimal C library termination procedures and returns to the caller. Doesn't terminate the process. |
 
-When you call the **`exit`**,  **`_Exit`** or **`_exit`** function, the destructors for any temporary or automatic objects that exist at the time of the call aren't called. An automatic object is a non-static local object defined in a function. A temporary object is an object that's created by the compiler, such as a value returned by a function call. To destroy an automatic object before you call **`exit`**, **`_Exit`**, or **`_exit`**, explicitly call the destructor for the object, as shown here:
+When you call the **`exit`**, **`_Exit`** or **`_exit`** function, the destructors for any temporary or automatic objects that exist at the time of the call aren't called. An automatic object is a non-static local object defined in a function. A temporary object is an object that's created by the compiler, such as a value returned by a function call. To destroy an automatic object before you call **`exit`**, **`_Exit`**, or **`_exit`**, explicitly call the destructor for the object, as shown here:
 
 ```cpp
 void last_fn() {}