Merge pull request #261 from Microsoft/master

merge master into live

Author: mikeblome

docs/atl/reference/cautovectorptr-class.md

@@ -82,7 +82,7 @@ class CAutoVectorPtr
 |[CAutoVectorPtr::m_p](#m_p)|The pointer data member variable.|  
 
 ## Remarks  
- This class provides methods for creating and managing a smart pointer, which will help protect against memory leaks by automatically freeing resources when it falls out of scope. `CAutoVectorPtr` is similar to `CAutoPtr`, the only difference being that `CAutoVectorPtr` uses [vector new[]](../../standard-library/new-operators.md#operator_new_arr) and [vector delete[]](../../standard-library/new-operators.md#operator_delete_arr) to allocate and free memory instead of the C++ **new** and **delete** operators. See [CAutoVectorPtrElementTraits](../../atl/reference/cautovectorptrelementtraits-class.md) if collection classes of `CAutoVectorPtr` are required.  
+ This class provides methods for creating and managing a smart pointer, which will help protect against memory leaks by automatically freeing resources when it falls out of scope. `CAutoVectorPtr` is similar to `CAutoPtr`, the only difference being that `CAutoVectorPtr` uses [vector new[]](../../standard-library/new-operators.md#op_new_arr) and [vector delete[]](../../standard-library/new-operators.md#op_delete_arr) to allocate and free memory instead of the C++ **new** and **delete** operators. See [CAutoVectorPtrElementTraits](../../atl/reference/cautovectorptrelementtraits-class.md) if collection classes of `CAutoVectorPtr` are required.  
 
 
  See [CAutoPtr](../../atl/reference/cautoptr-class.md) for an example of using a smart pointer class.  

docs/build/how-to-integrate-custom-tools-into-the-project-properties.md

@@ -1,7 +1,7 @@
 ---
 title: "How to: Integrate Custom Tools into the Project Properties | Microsoft Docs"
 ms.custom: ""
-ms.date: "11/04/2016"
+ms.date: "04/27/2016"
 ms.reviewer: ""
 ms.suite: ""
 ms.technology: 
@@ -45,17 +45,17 @@ You can add custom tool options to the Visual Studio **Property Pages** window b
 
 1.  In the XML editor, create an XML file.  
 
-2.  Save the file in the %ProgramFiles%\MSBuild\Microsoft.Cpp\v4.0\ folder. Every rule in the **Property Pages** window is represented by an XML file in this folder. Make sure that the file is uniquely named in the folder.  
+2.  Save the file in the Visual Studio 2017 `VCTargets\1033` folder. You will have a different path for each edition of Visual Studio 2017 that is installed and each language. For example, the folder path for Visual Studio Enterprise edition in English is `%ProgramFiles%\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\1033`. Adjust the path for your language and Visual Studio edition. Every rule in the **Property Pages** window is represented by an XML file in this folder. Make sure that the file is uniquely named in the folder.  
 
-3.  Copy the content of %ProgramFiles%\MSBuild\Microsoft.Cpp\v4.0\cl.xml, close it without saving changes, and then paste the content in your new XML file. You can use any XML schema file - this is just one that can be used so you start with a template.  
+3.  Copy the content of  `%ProgramFiles%\Microsoft Visual Studio\2017\<VS Edition>\Common7\IDE\VC\VCTargets\<LCID>\cl.xml`, close it without saving changes, and then paste the content in your new XML file. You can use any XML schema file - this is just one that can be used so you start with a template.  
 
 4.  In the new XML file, modify the content according to your requirements. Make sure to change the **Rule Name** and **Rule.DisplayName** at the top of the file.  
 
 5.  Save the changes and close the file.  
 
-6.  The XML files in %ProgramFiles%\MSBuild\Microsoft.Cpp\v4.0\ are loaded when Visual Studio starts. Therefore, to test the new file, restart Visual Studio.  
+6.  The XML files in `%ProgramFiles%\Microsoft Visual Studio\2017\<VS Edition>\Common7\IDE\VC\VCTargets\<LCID>` are loaded when Visual Studio starts. Therefore, to test the new file, restart Visual Studio.  
 
 7.  In **Solution Explorer**, right-click a project and then click **Properties**. In the **Property Pages** window, in the left pane, verify that there is a new node with the name of your Rule.  
 
 ## See Also  
- [MSBuild (Visual C++)](../build/msbuild-visual-cpp.md)
+ [MSBuild (Visual C++)](../build/msbuild-visual-cpp.md)

docs/build/reference/TOC.md

@@ -398,7 +398,7 @@
 #### [pgomgr](pgomgr.md)
 #### [pgosweep](pgosweep.md)
 ### [How to: Merge Multiple PGO Profiles into a Single Profile](how-to-merge-multiple-pgo-profiles-into-a-single-profile.md)
-# [Compiler Errors C2001 to C2499](../../error-messages/compiler-errors-1/TOC.md)
+# [Compiler Errors C999 to C2499](../../error-messages/compiler-errors-1/TOC.md)
 # [Compiler Errors C2500 to C3999](../../error-messages/compiler-errors-2/TOC.md)
 # [Compiler Warnings](../../error-messages/compiler-warnings/TOC.md)
 # [Tool Errors](../../error-messages/tool-errors/TOC.md)

docs/build/reference/zc-throwingnew-assume-operator-new-throws.md

@@ -48,7 +48,7 @@ When the `/Zc:throwingNew` option is specified, the compiler optimizes calls to
 
 ## Remarks  
 
-Since ISO C++98, the standard has specified that the default [operator new](../../standard-library/new-operators.md#operator_new) throws `std::bad_alloc` when memory allocation fails. Versions of Visual C++ up to Visual Studio 6.0 returned a null pointer on an allocation failure. Beginning in Visual Studio 2002, `operator new` conforms to the standard and throws on failure. To support code that uses the older allocation style, Visual Studio provides a linkable implementation of `operator new` in *nothrownew.obj* that returns a null pointer on failure. By default, the compiler also generates defensive null checks to prevent these older-style allocators from causing an immediate crash on failure. The `/Zc:throwingNew` option tells the compiler to leave out these null checks, on the assumption that all linked memory allocators conform to the standard. This does not apply to explicit non-throwing `operator new` overloads, which are declared by using an additional parameter of type `std::nothrow_t` and have an explicit `noexcept` specification.  
+Since ISO C++98, the standard has specified that the default [operator new](../../standard-library/new-operators.md#op_new) throws `std::bad_alloc` when memory allocation fails. Versions of Visual C++ up to Visual Studio 6.0 returned a null pointer on an allocation failure. Beginning in Visual Studio 2002, `operator new` conforms to the standard and throws on failure. To support code that uses the older allocation style, Visual Studio provides a linkable implementation of `operator new` in *nothrownew.obj* that returns a null pointer on failure. By default, the compiler also generates defensive null checks to prevent these older-style allocators from causing an immediate crash on failure. The `/Zc:throwingNew` option tells the compiler to leave out these null checks, on the assumption that all linked memory allocators conform to the standard. This does not apply to explicit non-throwing `operator new` overloads, which are declared by using an additional parameter of type `std::nothrow_t` and have an explicit `noexcept` specification.  
 
 Conceptually, to create an object on the free store, the compiler generates code to allocate its memory and then to invoke its constructor to initialize the memory. Because the Visual C++ compiler normally cannot tell if this code will be linked to a non-conforming, non-throwing allocator, by default it also generates a null check before calling the constructor. This prevents a null pointer dereference in the constructor call if a non-throwing allocation fails. In most cases, these checks are unnecessary, because the default `operator new` allocators throw instead of returning null pointers. The checks also have unfortunate side effects. They bloat the code size, they flood the branch predictor, and they inhibit other useful compiler optimizations such as devirtualization or const propagation out of the initialized object. The checks exist only to support code that links to *nothrownew.obj* or has custom non-conforming `operator new` implementations. If you do not use non-conforming `operator new`, we recommend you use `/Zc:throwingNew` to optimize your code.  
 

docs/c-runtime-library/reference/strstr-wcsstr-mbsstr-mbsstr-l.md

@@ -219,4 +219,4 @@ lazy found at position 36
  [strpbrk, wcspbrk, _mbspbrk, _mbspbrk_l](../../c-runtime-library/reference/strpbrk-wcspbrk-mbspbrk-mbspbrk-l.md)   
  [strrchr, wcsrchr, _mbsrchr, _mbsrchr_l](../../c-runtime-library/reference/strrchr-wcsrchr-mbsrchr-mbsrchr-l.md)   
  [strspn, wcsspn, _mbsspn, _mbsspn_l](../../c-runtime-library/reference/strspn-wcsspn-mbsspn-mbsspn-l.md)   
- [basic_string::find](../../standard-library/basic-string-class.md#basic_string__find)  
+ [basic_string::find](../../standard-library/basic-string-class.md#find)  

docs/c-runtime-library/secure-template-overloads.md

@@ -40,72 +40,76 @@ translation.priority.ht:
   - "zh-tw"
 ---
 # Secure Template Overloads
-Many CRT functions have been deprecated in favor of newer, security-enhanced versions (for example, `strcpy_s` is the more secure replacement for `strcpy`). The CRT provides template overloads to help ease the transition to the more secure variants.  
+Microsoft has deprecated many C Runtime library (CRT) functions in favor of security-enhanced versions. For example, `strcpy_s` is the more secure replacement for `strcpy`. The deprecated functions are common sources of security bugs, because they do not prevent operations that can overwrite memory. By default, the compiler produces a deprecation warning when you use one of these functions. The CRT provides C++ template overloads for these functions to help ease the transition to the more secure variants.  
 
- For example, this code generates a warning because `strcpy` is deprecated:  
+For example, this code snippet generates a warning because `strcpy` is deprecated:  
 
- `char szBuf[10];`  
+```cpp  
+char szBuf[10];  
+strcpy(szBuf, "test"); // warning: deprecated  
+```
   
- `strcpy(szBuf, "test"); // warning: deprecated`  
+The deprecation warning is there to tell you that your code may be unsafe. If you have verified that your code can't overwrite memory, you have several choices. You can choose to ignore the warning, you can define the symbol `_CRT_SECURE_NO_WARNINGS` before the include statements for the CRT headers to suppress the warning, or you can update your code to use `strcpy_s`:  
   
- You can ignore the warning. Define the symbol `_CRT_SECURE_NO_WARNINGS` to suppress the warning, or update the code to use `strcpy_s`:  
+```cpp  
+char szBuf[10];  
+strcpy_s(szBuf, 10, "test"); // security-enhanced _s function  
+```
 
- `char szBuf[10];`  
+The template overloads provide additional choices. If you define `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` to 1, this enables template overloads of standard CRT functions that call the more secure variants automatically. If `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` is 1, then no changes to your code are necessary. Behind the scenes, the call to `strcpy` is changed to a call to `strcpy_s` with the size argument supplied automatically.  
 
- `strcpy_s(szBuf, 10, "test"); // security-enhanced _s function`  
+```cpp  
+#define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1  
 
- The template overloads provide additional choices. Defining `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` to 1 enables template overloads of standard CRT functions that call the more secure variants automatically. If `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` is 1, then no changes to the code are necessary. Behind the scenes, the call to `strcpy` will be changed to a call to `strcpy_s` with the size argument supplied automatically.  
+// ...  
 
- `#define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1`  
+char szBuf[10];  
+strcpy(szBuf, "test"); // ==> strcpy_s(szBuf, 10, "test")  
+```  
   
- `...`  
-  
- `char szBuf[10];`  
-  
- `strcpy(szBuf, "test"); // ==> strcpy_s(szBuf, 10, "test")`  
-  
- `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` does not affect the functions that take a count, such as `strncpy`. To enable template overloads for the count functions, define `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_COUNT` to 1. Before doing so, however, make sure that your code passes the count of characters, not the size of the buffer (a common mistake). Also, code that explicitly writes a null terminator at the end of the buffer after the function call is unnecessary if the secure variant is called. If you need truncation behavior, see [_TRUNCATE](../c-runtime-library/truncate.md).  
+The macro `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` does not affect the functions that take a count, such as `strncpy`. To enable template overloads for the count functions, define `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_COUNT` to 1. Before doing so, however, make sure that your code passes the count of characters, not the size of the buffer (a common mistake). Also, code that explicitly writes a null terminator at the end of the buffer after the function call is unnecessary if the secure variant is called. If you need truncation behavior, see [_TRUNCATE](../c-runtime-library/truncate.md).  
   
 > [!NOTE]
 >  The macro `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_COUNT` requires that `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` is also defined as 1. If `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_COUNT` is defined as 1 and `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` is defined as 0, the application will not perform any template overloads.  
   
- Defining `_CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES` to 1 enables template overloads of the secure variants (names ending in "_s"). In this case, if `_CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES` is 1, then one small change must be made to the original code:  
-  
- `#define _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES 1`  
+When you define `_CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES` to 1, it enables template overloads of the secure variants (names ending in "_s"). In this case, if `_CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES` is 1, then one small change must be made to the original code:  
   
- `...`  
+```cpp  
+#define _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES 1  
   
- `char szBuf[10];`  
+// ...  
   
- `strcpy_s(szBuf, "test"); // ==> strcpy_s(szBuf, 10, "test")`  
+char szBuf[10];  
+strcpy_s(szBuf, "test"); // ==> strcpy_s(szBuf, 10, "test")  
+```  
 
- Only the name of the function needs to be changed (by adding "_s"); the template overload will take care of providing the size argument.  
+ Only the name of the function needs to be changed (by adding "_s"); the template overload takes care of providing the size argument.  
 
  By default, `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` and `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_COUNT` are defined as 0 (disabled) and `_CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES` is defined as 1 (enabled).  
 
  Note that these template overloads only work for static arrays. Dynamically allocated buffers require additional source code changes. Revisiting the above examples:  
 
- `#define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1`  
+```cpp  
+#define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1  
 
- `...`  
+// ...  
 
- `char *szBuf = (char*)malloc(10);`  
-  
- `strcpy(szBuf, "test"); // still deprecated; have to change to`  
-  
- `// strcpy_s(szBuf, 10, "test");`  
+char *szBuf = (char*)malloc(10);  
+strcpy(szBuf, "test"); // still deprecated; you have to change it to  
+                       // strcpy_s(szBuf, 10, "test");  
+```  
   
  And this:  
   
- `#define _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES 1`  
-  
- `...`  
-  
- `char *szBuf = (char*)malloc(10);`  
+```cpp  
+#define _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES 1  
   
- `strcpy_s(szBuf, "test"); // doesn't compile; have to change to`  
+// ...  
   
- `// strcpy_s(szBuf, 10, "test");`  
+char *szBuf = (char*)malloc(10);  
+strcpy_s(szBuf, "test"); // doesn't compile; you have to change it to  
+                         // strcpy_s(szBuf, 10, "test");  
+```  
 
 ## See Also  
  [Security Features in the CRT](../c-runtime-library/security-features-in-the-crt.md)   

docs/cpp-conformance-improvements-2017.md

@@ -278,16 +278,6 @@ static_assert(test2, "PASS2");
 ### Classes declared in anonymous namespaces
 According to the C++ standard, a class declared inside an anonymous namespace has internal linkage, and therefore cannot be exported. In Visual Studio 2015 and earlier, this rule was not enforced. In Visual Studio 2017 the rule is partially enforced. The following example raises this error in Visual Studio 2017: "error C2201: 'const `anonymous namespace'::S1::`vftable'': must have external linkage in order to be exported/imported."
 
-```cpp
-namespace
-{
-	struct __declspec(dllexport) S1 { virtual void f() {} }; //C2201
-}
-```
-
-### Classes declared in anonymous namespaces
-According to the C++ standard, a class declared inside an anonymous namespace has internal linkage, and therefore cannot be exported. In Visual Studio 2015 and earlier, this rule was not enforced. In Visual Studio 2017 the rule is partially enforced. The following example raises this error in Visual Studio 2017: "error C2201: 'const `anonymous namespace'::S1::`vftable'': must have external linkage in order to be exported/imported."
-
 ```cpp
 struct __declspec(dllexport) S1 { virtual void f() {} }; //C2201
 ```