Merge pull request MicrosoftDocs#3511 from corob-msft/docs/corob/more-masm-bnf-fixes

PRMerger8 · web-flow · commit 00e9d2b427f8 · 2021-04-16T11:42:39.000+05:30
Fix more issues in MASM BNF page and some stray gremlin chars.
diff --git a/docs/assembler/masm/masm-bnf-grammar.md b/docs/assembler/masm/masm-bnf-grammar.md
diff --git a/docs/build/cmake-presets-vs.md b/docs/build/cmake-presets-vs.md
@@ -123,15 +123,15 @@ In the example above:
 - **192.168.0.5** is a remote Linux system that was added to the **Connection Manager**.
 - **ubuntu2004** and **debian** are WSL installations.
 
-Select **Manage Connections…** to open the **Connection Manager**.
+Select **Manage Connections** to open the **Connection Manager**.
 
 ### Select a Configure Preset
 
 The dropdown in the middle indicates the active **Configure Preset**. It's the `configurePreset` that's used when CMake is invoked to generate the project build system. This dropdown lists the union of non-hidden Configure Presets defined in `CMakePresets.json` and `CMakeUserPresets.json`.
 
 Visual Studio will use the value of `hostOS` in the Microsoft Visual Studio Settings vendor map to hide Configure Presets that don't apply to the active Target System. For more information, see the entry for `hostOS` in the table under [Visual Studio Settings vendor map](cmake-presets-json-reference.md#visual-studio-settings-vendor-map).
 
-Select **Manage Configurations…** to open the `CMakePresets.json` file located at the root of the project. `CMakePresets.json` is created if it doesn't already exist.
+Select **Manage Configurations** to open the `CMakePresets.json` file located at the root of the project. `CMakePresets.json` is created if it doesn't already exist.
 
 ### Select a Build Preset
 
@@ -169,7 +169,7 @@ Use a forward slash (`/`) for paths in `CMakePresets.json` and `CMakeUserPresets
 
 ### Add new Configure Presets
 
-To add a new Configure Preset to `CMakePresets.json`, from **Solution Explorer** right-click `CMakePresets.json` from **Folder View** and select **Add Configure Preset…** from the context menu. The dialog to select a Configure Preset template appears:
+To add a new Configure Preset to `CMakePresets.json`, from **Solution Explorer** right-click `CMakePresets.json` from **Folder View** and select **Add Configure Preset** from the context menu. The dialog to select a Configure Preset template appears:
 
 ![Add configure preset to `CMakePresets.json` dialog](./media/add-configure-preset-to-cmakepresets.png)
 
diff --git a/docs/build/reference/module-exportheader.md b/docs/build/reference/module-exportheader.md
@@ -42,13 +42,13 @@ You may find it helpful to use the complementary option **`/showResolvedHeader`*
 To build a header unit such as `<vector>` might look like:
 
 ```cmd
-cl … /std:c++latest /exportHeader /headerName:angle vector
+cl . . . /std:c++latest /exportHeader /headerName:angle vector
 ```
 
 Building a local project header such as `"utils/util.h"` might look like:
 
 ```cmd
-cl … /std:c++latest /exportHeader /headerName:quote util/util.h
+cl . . . /std:c++latest /exportHeader /headerName:quote util/util.h
 ```
 
 ### To set this compiler option in the Visual Studio development environment
diff --git a/docs/c-runtime-library/reference/set-unexpected-crt.md b/docs/c-runtime-library/reference/set-unexpected-crt.md
@@ -43,7 +43,7 @@ Unlike the custom termination function installed by a call to **`set_terminate`*
 
 In a multithreaded environment, unexpected functions are maintained separately for each thread. Each new thread needs to install its own unexpected function. Thus, each thread is in charge of its own unexpected handling.
 
-In the current Microsoft implementation of C++ exception handling, **`unexpected`** calls **`terminate`** by default and is never called by the exception-handling run-time library. There is no particular advantage to calling **`unexpected`** rather than **term`inate**.
+In the current Microsoft implementation of C++ exception handling, **`unexpected`** calls **`terminate`** by default and is never called by the exception-handling run-time library. There is no particular advantage to calling **`unexpected`** rather than **`terminate`**.
 
 There is a single **`set_unexpected`** handler for all dynamically linked DLLs or EXEs; even if you call **`set_unexpected`** your handler may be replaced by another or that you are replacing a handler set by another DLL or EXE.
 
diff --git a/docs/c-runtime-library/reference/strcpy-s-wcscpy-s-mbscpy-s.md b/docs/c-runtime-library/reference/strcpy-s-wcscpy-s-mbscpy-s.md
@@ -10,7 +10,7 @@ f1_keywords: ["strcpy_s", "_mbscpy_s", "_mbscpy_s_l", "_tcscpy_s", "wcscpy_s"]
 helpviewer_keywords: ["strcpy_s function", "_tcscpy_s function", "_mbscpy_s function", "_mbscpy_s_l function", "copying strings", "strings [C++], copying", "tcscpy_s function", "wcscpy_s function"]
 ms.assetid: 611326f3-7929-4a5d-a465-a4683af3b053
 ---
-# `strcpy_s`, `wcscpy_`s, `_mbscpy_s`, `_mbscpy_s_l`
+# `strcpy_s`, `wcscpy_s`, `_mbscpy_s`, `_mbscpy_s_l`
 
 Copies a string. These versions of [`strcpy`, `wcscpy`, `_mbscpy`](strcpy-wcscpy-mbscpy.md) have security enhancements, as described in [Security Features in the CRT](../../c-runtime-library/security-features-in-the-crt.md).
 
diff --git a/docs/c-runtime-library/tgmath.md b/docs/c-runtime-library/tgmath.md
@@ -10,7 +10,7 @@ helpviewer_keywords: ["CRT tgmath.h"]
 
 For ISO C Standard 11 (C11) and later, the `<tgmath.h>` header, in addition to including `<math.h>` and `<complex.h>`, provides macros that invoke a corresponding math function based on the types of the parameters.
 
-C runtime library math functions come in real and complex variants. Each variant comes in three flavors, depending on the type of the argument: `float`, `double`, and `long double`. Because C doesn't support overloading like C++ does, each variant has a different name. For example, to get the absolute value of a real floating-point value, you'd call either `fabsf`, `fabs`, or `fabsl` depending on whether you're passing a `float`, `double`, or `long double` value, respectively. To get the complex absolute value, you'd call one of `cabsf`, `cabs`, or `cabsl` depending on whether you're passing a `float`, `double`, and `long double`complex value, respectively. If the arguments do not match any of the above mentioned types, the function is chosen as though the arguments were doubles.
+C runtime library math functions come in real and complex variants. Each variant comes in three flavors, depending on the type of the argument: `float`, `double`, and `long double`. Because C doesn't support overloading like C++ does, each variant has a different name. For example, to get the absolute value of a real floating-point value, you'd call either `fabsf`, `fabs`, or `fabsl` depending on whether you're passing a `float`, `double`, or `long double` value, respectively. To get the complex absolute value, you'd call one of `cabsf`, `cabs`, or `cabsl` depending on whether you're passing a `float`, `double`, and `long double` complex value, respectively. If the arguments do not match any of the above mentioned types, the function is chosen as though the arguments were doubles.
 
 `<tgmath.h>` contains macros that simplify the selection of the right math function to call. The macros examine the type they're passed and then call the right function. For example, the `sqrt` macro binds `sqrt(9.9f)` to `sqrtf()`, but it binds `sqrt(9.9)` to `sqrt()`. If at least one macro argument for a generic parameter is complex, then the macro binds to a complex function; otherwise, it invokes a real function.
 
diff --git a/docs/code-quality/c6273.md b/docs/code-quality/c6273.md
@@ -15,7 +15,7 @@ This warning indicates that the format string specifies an integer, for example,
 
 ## Example
 
-The following code generates this warning because an integer is required instead of a **`float`** to `sprintf`function:
+The following code generates this warning because an integer is required instead of a **`float`** to `sprintf` function:
 
 ```cpp
 #include <stdio.h>
diff --git a/docs/cpp/import-export-module.md b/docs/cpp/import-export-module.md
@@ -105,7 +105,7 @@ In Microsoft C++, the tokens **import** and **module** are always identifiers an
 ### Example
 
 ```cpp
-#define foo(…) __VA_ARGS__
+#define foo(...) __VA_ARGS__
 foo(
 import // Always an identifier, never a keyword
 )
diff --git a/docs/mfc/activex-controls.md b/docs/mfc/activex-controls.md
@@ -10,7 +10,7 @@ ms.assetid: 52aaec4d-3889-402e-b57d-758078f8ac57
 In Visual C++ you can create ActiveX controls using MFC or ATL.
 
 >[!IMPORTANT]
-> ActiveX is a legacy technology that should not be used for new development. Many capabilities of ActiveX controls can be performed in a simpler and much more secure way with modern technologies such as HTML5 and JavaScript, modern browser extensions, or WebAssembly modules. For more information, see [A break from the past, part 2: Saying goodbye to ActiveX, VBScript, attachEvent…](https://blogs.windows.com/msedgedev/2015/05/06/a-break-from-the-past-part-2-saying-goodbye-to-activex-vbscript-attachevent/) and [Native Messaging](/microsoft-edge/extensions/guides/native-messaging) and [Microsoft Edge extensions](/microsoft-edge/extensions) and [WebAssembly](https://webassembly.org/).
+> ActiveX is a legacy technology that should not be used for new development. Many capabilities of ActiveX controls can be performed in a simpler and much more secure way with modern technologies such as HTML5 and JavaScript, modern browser extensions, or WebAssembly modules. For more information, see [A break from the past, part 2: Saying goodbye to ActiveX, VBScript, attachEvent](https://blogs.windows.com/msedgedev/2015/05/06/a-break-from-the-past-part-2-saying-goodbye-to-activex-vbscript-attachevent/) and [Native Messaging](/microsoft-edge/extensions/guides/native-messaging) and [Microsoft Edge extensions](/microsoft-edge/extensions) and [WebAssembly](https://webassembly.org/).
 
 - [MFC ActiveX Controls](mfc-activex-controls.md)
 
diff --git a/docs/overview/cpp-conformance-improvements.md b/docs/overview/cpp-conformance-improvements.md
@@ -173,7 +173,7 @@ To avoid the error, remove the **`constexpr`** modifier from the function declar
 In Visual Studio 2019, the `basic_string` range constructor no longer suppresses compiler diagnostics with **`static_cast`**. The following code compiles without warnings in Visual Studio 2017, despite the possible loss of data from **`wchar_t`** to **`char`** when initializing `out`:
 
 ```cpp
-std::wstring ws = /* … */;
+std::wstring ws = /* . . . */;
 std::string out(ws.begin(), ws.end()); // VS2019 C4244: 'argument': conversion from 'wchar_t' to 'const _Elem', possible loss of data.
 ```
 

Original file line number	Diff line number	Diff line change
`@@ -105,7 +105,7 @@ In Microsoft C++, the tokens import and module are always identifiers an`
`105`	`105`	`### Example`
`106`	`106`
`107`	`107`	```cpp
`108`		`-#define foo(…) __VA_ARGS__`
	`108`	`+#define foo(...) __VA_ARGS__`
`109`	`109`	`foo(`
`110`	`110`	`import // Always an identifier, never a keyword`
`111`	`111`	`)`