MicrosoftDocs · learn-build-service-prod · Mar 1, 2024 · Feb 28, 2024 · Feb 29, 2024 · Feb 29, 2024
diff --git a/docs/build/reference/winmd-generate-windows-metadata.md b/docs/build/reference/winmd-generate-windows-metadata.md
@@ -24,7 +24,7 @@ The linker generates only the .winmd file, but not the binary executable file.
 
 ## Remarks
 
-The **/WINMD** linker option is used for UWP apps and Windows runtime components to control the creation of a Windows Runtime metadata (.winmd) file. A .winmd file is a kind of DLL that contains metadata for Windows runtime types and, in the case of runtime components, the implementations of those types. The metadata follows the [ECMA-335](https://www.ecma-international.org/publications/standards/Ecma-335.htm) standard.
+The **/WINMD** linker option is used for UWP apps and Windows runtime components to control the creation of a Windows Runtime metadata (.winmd) file. A .winmd file is a kind of DLL that contains metadata for Windows runtime types and, in the case of runtime components, the implementations of those types. The metadata follows the [ECMA-335](https://ecma-international.org/publications-and-standards/standards/ecma-335/) standard.
 
 By default, the output file name has the form *binaryname*.winmd. To specify a different file name, use the [/WINMDFILE](winmdfile-specify-winmd-file.md) option.
 

diff --git a/...ntime-library/reference/fstat-fstat32-fstat64-fstati64-fstat32i64-fstat64i32.md b/...ntime-library/reference/fstat-fstat32-fstat64-fstati64-fstat32i64-fstat64i32.md
@@ -22,11 +22,11 @@ int _fstat(
 );
 int _fstat32(
    int fd,
-   struct __stat32 *buffer
+   struct _stat32 *buffer
 );
 int _fstat64(
    int fd,
-   struct __stat64 *buffer
+   struct _stat64 *buffer
 );
 int _fstati64(
    int fd,
@@ -73,7 +73,7 @@ If *`fd`* refers to a device, the **`st_atime`**, **`st_ctime`**, **`st_mtime`**
 
 Because `Stat.h` uses the [`_dev_t`](../standard-types.md) type, which is defined in `Types.h`, you must include `Types.h` before `Stat.h` in your code.
 
-**`_fstat64`**, which uses the `__stat64` structure, allows file-creation dates to be expressed up through 23:59:59, December 31, 3000, UTC; whereas the other functions only represent dates through 23:59:59 January 18, 2038, UTC. The lower bound of the date range for all these functions is Midnight, January 1, 1970.
+**`_fstat64`**, which uses the `_stat64` structure, allows file-creation dates to be expressed up through 23:59:59, December 31, 3000, UTC; whereas the other functions only represent dates through 23:59:59 January 18, 2038, UTC. The lower bound of the date range for all these functions is Midnight, January 1, 1970.
 
 Variations of these functions support 32-bit or 64-bit time types and 32-bit or 64-bit file lengths. The first numerical suffix (**`32`** or **`64`**) indicates the size of the time type used; the second suffix is either **`i32`** or **`i64`**, indicating whether the file size is represented as a 32-bit or 64-bit integer.
 

diff --git a/docs/c-runtime-library/reference/memcpy-wmemcpy.md b/docs/c-runtime-library/reference/memcpy-wmemcpy.md
@@ -8,7 +8,6 @@ api_type: ["DLLExport"]
 topic_type: ["apiref"]
 f1_keywords: ["wmemcpy", "memcpy"]
 helpviewer_keywords: ["wmemcpy function", "memcpy function"]
-ms.assetid: 34abb90b-bffb-46dc-a2f3-a5e9940839d6
 ---
 # `memcpy`, `wmemcpy`
 
@@ -49,14 +48,14 @@ The value of *`dest`*.
 **`memcpy`** copies *`count`* bytes from *`src`* to *`dest`*; **`wmemcpy`** copies *`count`* wide characters. If the source and destination regions overlap, the behavior of **`memcpy`** is undefined. Use **`memmove`** to handle overlapping regions.
 
 > [!IMPORTANT]
-> Make sure that the destination buffer is the same size or larger than the source buffer. For more information, see [Avoiding buffer overruns](/windows/win32/SecBP/avoiding-buffer-overruns).
+> Make sure that the destination buffer is large enough to accommodate the number of copied characters. For more information, see [Avoiding buffer overruns](/windows/win32/SecBP/avoiding-buffer-overruns).
 
 > [!IMPORTANT]
 > Because so many buffer overruns, and thus potential security exploits, have been traced to improper usage of **`memcpy`**, this function is listed among the "banned" functions by the Security Development Lifecycle (SDL).  You may observe that some VC++ library classes continue to use **`memcpy`**.  Furthermore, you may observe that the VC++ compiler optimizer sometimes emits calls to **`memcpy`**.  The Visual C++ product is developed in accordance with the SDL process, and thus usage of this banned function has been closely evaluated.  In the case of library use of it, the calls have been carefully scrutinized to ensure that buffer overruns will not be allowed through these calls.  In the case of the compiler, sometimes certain code patterns are recognized as identical to the pattern of **`memcpy`**, and are thus replaced with a call to the function.  In such cases, the use of **`memcpy`** is no more unsafe than the original instructions would have been; they have simply been optimized to a call to the performance-tuned **`memcpy`** function.  Just as the use of "safe" CRT functions doesn't guarantee safety (they just make it harder to be unsafe), the use of "banned" functions doesn't guarantee danger (they just require greater scrutiny to ensure safety).
 >
 > Because **`memcpy`** usage by the VC++ compiler and libraries has been so carefully scrutinized, these calls are permitted within code that otherwise conforms with the SDL.  **`memcpy`** calls introduced in application source code only conform with the SDL when that use has been reviewed by security experts.
 
-The **`memcpy`** and **`wmemcpy`** functions are only deprecated if the constant `_CRT_SECURE_DEPRECATE_MEMORY` is defined before the include statement, as in the example below:
+The **`memcpy`** and **`wmemcpy`** functions are only deprecated if the constant `_CRT_SECURE_DEPRECATE_MEMORY` is defined before the `#include` statement, as in the following examples:
 
 ```C
 #define _CRT_SECURE_DEPRECATE_MEMORY

diff --git a/docs/c-runtime-library/reference/memmove-wmemmove.md b/docs/c-runtime-library/reference/memmove-wmemmove.md
@@ -47,9 +47,9 @@ The value of *`dest`*.
 
 Copies *`count`* bytes (**`memmove`**) or characters (**`wmemmove`**) from *`src`* to *`dest`*. If some portions of the source and the destination regions overlap, both functions ensure that the original source bytes in the overlapping region are copied before being overwritten.
 
-**Security Note** Make sure that the destination buffer is the same size or larger than the source buffer. For more information, see [Avoiding buffer overruns](/windows/win32/SecBP/avoiding-buffer-overruns).
+**Security Note** Make sure that the destination buffer is large enough to accommodate the number of moved characters. For more information, see [Avoiding buffer overruns](/windows/win32/SecBP/avoiding-buffer-overruns).
 
-The **`memmove`** and **`wmemmove`** functions will only be deprecated if the constant `_CRT_SECURE_DEPRECATE_MEMORY` is defined before the inclusion statement in order for the functions to be deprecated, such as in the example below:
+The **`memmove`** and **`wmemmove`** functions are only deprecated if the constant `_CRT_SECURE_DEPRECATE_MEMORY` is defined before the `#include` statement, as shown in the following example:
 
 ```C
 #define _CRT_SECURE_DEPRECATE_MEMORY

diff --git a/docs/c-runtime-library/reference/toupper-toupper-towupper-toupper-l-towupper-l.md b/docs/c-runtime-library/reference/toupper-toupper-towupper-toupper-l-towupper-l.md
@@ -8,7 +8,6 @@ api_type: ["DLLExport"]
 topic_type: ["apiref"]
 f1_keywords: ["CTYPE/toupper", "CTYPE/_toupper", "CTYPE/_toupper_l", "CORECRT_WCTYPE/towupper", "CORECRT_WCTYPE/_towupper_l", "TCHAR/_totupper", "TCHAR/_totupper_l", "toupper", "_toupper", "_toupper_l", "towupper", "_towupper_l", "_totupper", "_totupper_l"]
 helpviewer_keywords: ["_toupper function", "towupper function", "uppercase, converting strings to", "totupper function", "string conversion, to different characters", "towupper_l function", "toupper_l function", "string conversion, case", "_toupper_l function", "_towupper_l function", "_totupper function", "case, converting", "characters, converting", "toupper function"]
-ms.assetid: cdef1b0f-b19c-4d11-b7d2-cf6334c9b6cc
 ---
 # `toupper`, `_toupper`, `towupper`, `_toupper_l`, `_towupper_l`
 
@@ -52,19 +51,17 @@ If *`c`* is a wide character for which `iswlower` is nonzero and there's a corre
 
 There's no return value reserved to indicate an error.
 
-In order for **`toupper`** to give the expected results, [`__isascii`](isascii-isascii-iswascii.md) and [`islower`](islower-iswlower-islower-l-iswlower-l.md) must both return nonzero.
-
 ## Remarks
 
 Each of these routines converts a given lowercase letter to an uppercase letter if possible and appropriate. The case conversion of **`towupper`** is locale-specific. Only the characters relevant to the current locale are changed in case. The functions without the `_l` suffix use the currently set locale. The versions of these functions with the `_l` suffix take the locale as a parameter and use that instead of the currently set locale. For more information, see [Locale](../locale.md).
 
-In order for **`toupper`** to give the expected results, [`__isascii`](isascii-isascii-iswascii.md) and [`isupper`](isupper-isupper-l-iswupper-iswupper-l.md) must both return nonzero.
+For **`toupper`** to give the expected results, [`__isascii`](isascii-isascii-iswascii.md) must return nonzero.
 
 By default, this function's global state is scoped to the application. To change this behavior, see [Global state in the CRT](../global-state.md).
 
 ### Generic-text routine mappings
 
-| TCHAR.H routine | `_UNICODE` and `_MBCS` not defined | `_MBCS` defined | `_UNICODE` defined |
+| `TCHAR.H` routine | `_UNICODE` and `_MBCS` not defined | `_MBCS` defined | `_UNICODE` defined |
 |---|---|---|---|
 | `_totupper` | **`toupper`** | **`_mbctoupper`** | **`towupper`** |
 | `_totupper_l` | **`_toupper_l`** | **`_mbctoupper_l`** | **`_towupper_l`** |

diff --git a/docs/c-runtime-library/rtdynamiccast.md b/docs/c-runtime-library/rtdynamiccast.md
@@ -8,7 +8,6 @@ api_type: ["DLLExport"]
 topic_type: ["apiref"]
 f1_keywords: ["RTTIDATA/__RTDynamicCast", "__RTDynamicCast"]
 helpviewer_keywords: ["__RTDynamicCast"]
-ms.assetid: 56aa2d7a-aa47-46ef-830d-e37175611239
 ---
 # `__RTDynamicCast`
 
@@ -17,13 +16,13 @@ Runtime implementation of the [`dynamic_cast`](../cpp/dynamic-cast-operator.md)
 ## Syntax
 
 ```cpp
-PVOID __RTDynamicCast (
+PVOID __RTDynamicCast(
    PVOID inptr,
    LONG VfDelta,
    PVOID SrcType,
    PVOID TargetType,
    BOOL isReference
-   ) throw(...)
+) throw(...)
 ```
 
 #### Parameters
@@ -45,7 +44,7 @@ Intended result of cast.
 
 ## Return value
 
-Pointer to the appropriate subobject, if successful; otherwise, `NULL`.
+Pointer to the appropriate subobject if successful; otherwise, `NULL`.
 
 ## Exceptions
 
@@ -59,4 +58,4 @@ Converts `inptr` to an object of type `TargetType`. The type of `inptr` must be
 
 | Routine | Required header |
 |---|---|
-| **`__RTDynamicCast`** | `<rtti.h>` |
+| **`__RTDynamicCast`** | `<rttidata.h>` |
diff --git a/docs/cpp/identifiers-cpp.md b/docs/cpp/identifiers-cpp.md
@@ -77,7 +77,7 @@ int main() {
 }
 ```
 
-The range of characters allowed in an identifier is less restrictive when compiling C++/CLI code. Identifiers in code compiled by using /clr should follow  [Standard ECMA-335: Common Language Infrastructure (CLI)](https://www.ecma-international.org/publications/standards/Ecma-335.htm).
+The range of characters allowed in an identifier is less restrictive when compiling C++/CLI code. Identifiers in code compiled by using /clr should follow  [Standard ECMA-335: Common Language Infrastructure (CLI)](https://ecma-international.org/publications-and-standards/standards/ecma-335/).
 
 **END Microsoft Specific**
 

diff --git a/docs/cross-platform/install-and-configure-tools-to-build-using-ios.md b/docs/cross-platform/install-and-configure-tools-to-build-using-ios.md
@@ -26,7 +26,7 @@ To install and use the vcremote remote agent to develop code for iOS, you must f
 
    You can get a free account that allows sideloading apps to an iOS device for testing only but not for distribution.
 
-- [Xcode](https://developer.apple.com/xcode/downloads/) version 10.2.1 or later
+- [Xcode](https://apps.apple.com/us/app/xcode/id497799835?mt=12/) version 10.2.1 or later
 
    Xcode can be downloaded from the App Store.
 

diff --git a/docs/error-messages/compiler-errors-2/compiler-error-c3872.md b/docs/error-messages/compiler-errors-2/compiler-error-c3872.md
@@ -12,7 +12,7 @@ ms.assetid: 519e95be-5641-40cc-894c-da4819506604
 
 The C++ compiler follows the C++11 standard on characters allowed in an identifier. Only certain ranges of characters and universal character names are allowed in an identifier. Additional restrictions apply to the initial character of an identifier. For more information and a list of allowed characters and universal character name ranges, see [Identifiers](../../cpp/identifiers-cpp.md).
 
-The range of characters allowed in an identifier is less restrictive when compiling C++/CLI code. Identifiers in code compiled by using /clr should follow  [Standard ECMA-335: Common Language Infrastructure (CLI)](https://www.ecma-international.org/publications/standards/Ecma-335.htm).
+The range of characters allowed in an identifier is less restrictive when compiling C++/CLI code. Identifiers in code compiled by using /clr should follow  [Standard ECMA-335: Common Language Infrastructure (CLI)](https://ecma-international.org/publications-and-standards/standards/ecma-335/).
 
 The following sample generates C3872:
 

diff --git a/docs/error-messages/compiler-errors-2/compiler-error-c3873.md b/docs/error-messages/compiler-errors-2/compiler-error-c3873.md
@@ -12,7 +12,7 @@ ms.assetid: e68fd3be-2391-492b-ac3f-d2428901b2e9
 
 The C++ compiler follows the C++11 standard on characters allowed in an identifier. Only certain ranges of characters and universal character names are allowed in an identifier. Additional restrictions apply to the initial character of an identifier. For more information and a list of allowed characters and universal character name ranges, see [Identifiers](../../cpp/identifiers-cpp.md).
 
-The range of characters allowed in an identifier is less restrictive when compiling C++/CLI code. Identifiers in code compiled by using /clr should follow  [Standard ECMA-335: Common Language Infrastructure (CLI)](https://www.ecma-international.org/publications/standards/Ecma-335.htm).
+The range of characters allowed in an identifier is less restrictive when compiling C++/CLI code. Identifiers in code compiled by using /clr should follow  [Standard ECMA-335: Common Language Infrastructure (CLI)](https://ecma-international.org/publications-and-standards/standards/ecma-335/).
 
 The following sample generates C3873:
 

diff --git a/docs/intrinsics/arm-intrinsics.md b/docs/intrinsics/arm-intrinsics.md
@@ -166,6 +166,8 @@ The primary difference between MSVC and the ARM compiler is that the MSVC adds `
 |_CountLeadingSigns64||unsigned int _CountLeadingSigns64(\__int64)|
 |_CountLeadingZeros||unsigned int _CountLeadingZeros(unsigned long)|
 |_CountLeadingZeros64||unsigned int _CountLeadingZeros64(unsigned \__int64)|
+|_CountTrailingZeros||unsigned _CountTrailingZeros(unsigned long)|
+|_CountTrailingZeros64||unsigned _CountTrailingZeros64(unsigned \__int64)|
 |_CountOneBits||unsigned int _CountOneBits(unsigned long)|
 |_CountOneBits64||unsigned int _CountOneBits64(unsigned \__int64)|
 |_DAddSatInt|QDADD|int _DAddSatInt(int, int)|

diff --git a/docs/overview/cpp-conformance-improvements-2019.md b/docs/overview/cpp-conformance-improvements-2019.md
@@ -465,7 +465,7 @@ We fixed a minor type traits bug, where `add_const_t` and related functions are
 
 ### char8_t
 
-[P0482r6](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0482r6.html). C++20 adds a new character type that is used to represent UTF-8 code units. `u8` string literals in C++20 have type `const char8_t[N]` instead of `const char[N]`, which was the case previously. Similar changes have been proposed for the C standard in [N2231](https://wg14.link/n2231). Suggestions for **`char8_t`** backward compatibility remediation are given in [P1423r3](https://wg21.link/p1423r3). The Microsoft C++ compiler adds support for **`char8_t`** in Visual Studio 2019 version 16.1 when you specify the [`/Zc:char8_t`](../build/reference/zc-char8-t.md) compiler option. It can be reverted to C++17 behavior via **`/Zc:char8_t-`**. The EDG compiler that powers IntelliSense doesn't yet support it in Visual Studio 2019 version 16.1. You may see spurious IntelliSense-only errors that don't affect the actual compilation.
+[P0482r6](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0482r6.html). C++20 adds a new character type that is used to represent UTF-8 code units. `u8` string literals in C++20 have type `const char8_t[N]` instead of `const char[N]`, which was the case previously. Similar changes have been proposed for the C standard in [N2231](https://open-std.org/jtc1/sc22/wg14/www/docs/n2231.htm). Suggestions for **`char8_t`** backward compatibility remediation are given in [P1423r3](https://wg21.link/p1423r3). The Microsoft C++ compiler adds support for **`char8_t`** in Visual Studio 2019 version 16.1 when you specify the [`/Zc:char8_t`](../build/reference/zc-char8-t.md) compiler option. It can be reverted to C++17 behavior via **`/Zc:char8_t-`**. The EDG compiler that powers IntelliSense doesn't yet support it in Visual Studio 2019 version 16.1. You may see spurious IntelliSense-only errors that don't affect the actual compilation.
 
 #### Example
-Original file line number
+Diff line change
@@ Expand Up / @@ -77,7 +77,7 @@ int main() { @@
     }
     ```
-    The range of characters allowed in an identifier is less restrictive when compiling C++/CLI code. Identifiers in code compiled by using /clr should follow  [Standard ECMA-335: Common Language Infrastructure (CLI)](https://www.ecma-international.org/publications/standards/Ecma-335.htm).
+    The range of characters allowed in an identifier is less restrictive when compiling C++/CLI code. Identifiers in code compiled by using /clr should follow  [Standard ECMA-335: Common Language Infrastructure (CLI)](https://ecma-international.org/publications-and-standards/standards/ecma-335/).
     **END Microsoft Specific**
@@ Expand Down @@