Standardize use of POSIX

Colin Robertson · Colin Robertson · commit 56066acb6e52 · 2019-12-02T14:52:49.000-08:00
diff --git a/docs/c-runtime-library/errno-constants.md b/docs/c-runtime-library/errno-constants.md
@@ -44,7 +44,7 @@ The following **errno** values are supported:
 |**EXDEV**|Cross-device link. An attempt was made to move a file to a different device (using the **rename** function).|
 |**STRUNCATE**|A string copy or concatenation resulted in a truncated string. See [_TRUNCATE](../c-runtime-library/truncate.md).
 
-The following values are supported for compatibility with Posix. They are required values on non-Posix systems.
+The following values are supported for compatibility with POSIX. They are required values on non-POSIX systems.
 
 ```C
 #define E2BIG /* argument list too long */
diff --git a/docs/c-runtime-library/reference/itoa-itow.md b/docs/c-runtime-library/reference/itoa-itow.md
@@ -28,7 +28,7 @@ wchar_t * _ultow( unsigned long value, wchar_t *buffer, int radix );
 wchar_t * _i64tow( long long value, wchar_t *buffer, int radix );
 wchar_t * _ui64tow( unsigned long long value, wchar_t *buffer, int radix );
 
-// These Posix versions of the functions have deprecated names:
+// These POSIX versions of the functions have deprecated names:
 char * itoa( int value, char *buffer, int radix );
 char * ltoa( long value, char *buffer, int radix );
 char * ultoa( unsigned long value, char *buffer, int radix );
@@ -102,9 +102,9 @@ To use these functions without the deprecation warning, define the **_CRT_SECURE
 
 In C++, these functions have template overloads that invoke their safer counterparts. For more information, see [Secure Template Overloads](../../c-runtime-library/secure-template-overloads.md).
 
-The Posix names **itoa**, **ltoa**, and **ultoa** exist as aliases for the **_itoa**, **_ltoa**, and **_ultoa** functions. The Posix names are deprecated because they do not follow the implementation-specific function name conventions of ISO C. By default, these functions cause deprecation warning [C4996](../../error-messages/compiler-warnings/compiler-warning-level-3-c4996.md): **The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name:** *new_name*. We recommend you change your source code to use the safer versions of these functions, **_itoa_s**, **_ltoa_s**, or **_ultoa_s**. For more information, see [_itoa_s, _itow_s functions](itoa-s-itow-s.md).
+The POSIX names **itoa**, **ltoa**, and **ultoa** exist as aliases for the **_itoa**, **_ltoa**, and **_ultoa** functions. The POSIX names are deprecated because they do not follow the implementation-specific global function name conventions of ISO C. By default, these functions cause deprecation warning [C4996](../../error-messages/compiler-warnings/compiler-warning-level-3-c4996.md): **The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name:** *new_name*. We recommend you change your source code to use the safer versions of these functions, **_itoa_s**, **_ltoa_s**, or **_ultoa_s**. For more information, see [_itoa_s, _itow_s functions](itoa-s-itow-s.md).
 
-For source code portability, you may prefer to retain the Posix names in your code. To use these functions without the deprecation warning, define both the **_CRT_NONSTDC_NO_WARNINGS** and **_CRT_SECURE_NO_WARNINGS** preprocessor macros before including any CRT headers. You can do this on the command line in a developer command prompt by adding the **/D_CRT_SECURE_NO_WARNINGS** and **/D_CRT_NONSTDC_NO_WARNINGS** compiler options to the **cl** command. Otherwise, define the macros in your source files. If you use precompiled headers, define the macros at the top of the precompiled header include file. To define the macros in your source code, use **#define** directives before you include any CRT header, as in this example:
+For source code portability, you may prefer to retain the POSIX names in your code. To use these functions without the deprecation warning, define both the **_CRT_NONSTDC_NO_WARNINGS** and **_CRT_SECURE_NO_WARNINGS** preprocessor macros before including any CRT headers. You can do this on the command line in a developer command prompt by adding the **/D_CRT_SECURE_NO_WARNINGS** and **/D_CRT_NONSTDC_NO_WARNINGS** compiler options to the **cl** command. Otherwise, define the macros in your source files. If you use precompiled headers, define the macros at the top of the precompiled header include file. To define the macros in your source code, use **#define** directives before you include any CRT header, as in this example:
 
 ```C
 #define _CRT_NONSTDC_NO_WARNINGS 1
diff --git a/docs/error-messages/compiler-warnings/compiler-warning-level-3-c4996.md b/docs/error-messages/compiler-warnings/compiler-warning-level-3-c4996.md
@@ -15,7 +15,7 @@ Your code uses a function, class member, variable, or typedef that's marked *dep
 
 ## Remarks
 
-Many functions, member functions, template functions, and global variables in Visual Studio libraries are *deprecated*. Some, such as Posix functions, are deprecated because they have a different preferred name. Some C runtime library functions are deprecated because they're insecure and have a more secure variant. Others are deprecated because they're obsolete. The deprecation messages usually include a suggested replacement for the deprecated function or global variable.
+Many functions, member functions, template functions, and global variables in Visual Studio libraries are *deprecated*. Some, such as POSIX and Microsoft-specific functions, are deprecated because they now have a different preferred name. Some C runtime library functions are deprecated because they're insecure and have a more secure variant. Others are deprecated because they're obsolete. The deprecation messages usually include a suggested replacement for the deprecated function or global variable.
 
 ## Turn off the warning
 
@@ -53,9 +53,9 @@ Here are some of the common sources of C4996 warnings and errors:
 
 **The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name:** *new-name*. **See online help for details.**
 
-Microsoft renamed some POSIX functions in the CRT to conform with C99 and C++03 rules for implementation-defined global function names. Only the names are deprecated, not the functions themselves. In most cases, a leading underscore was added to the POSIX function name to create a standards conformant name. The compiler issues a deprecation warning for the original function name, and suggests the preferred name.
+Microsoft renamed some POSIX and Microsoft-specific library functions in the CRT to conform with C99 and C++03 constraints on reserved and global implementation-defined names. *Only the names are deprecated, not the functions themselves*. In most cases, a leading underscore was added to the function name to create a conforming name. The compiler issues a deprecation warning for the original function name, and suggests the preferred name.
 
-To fix this issue, we usually recommend you change your code to use the suggested function names instead. However, the updated names are Microsoft-specific. If you need to use the existing function names for portability reasons, you can turn off these warnings. The POSIX functions are still available in the library under their original names.
+To fix this issue, we usually recommend you change your code to use the suggested function names instead. However, the updated names are Microsoft-specific. If you need to use the existing function names for portability reasons, you can turn off these warnings. The functions are still available in the library under their original names.
 
 To turn off deprecation warnings for these functions, define the preprocessor macro **\_CRT\_NONSTDC\_NO\_WARNINGS**. You can define this macro at the command line by including the option `/D_CRT_NONSTDC_NO_WARNINGS`.
 
diff --git a/docs/standard-library/filesystem-functions.md b/docs/standard-library/filesystem-functions.md
@@ -479,7 +479,7 @@ path system_complete(const path& pval);
 path system_complete(const path& pval, error_code& ec);
 ```
 
-The functions return an absolute pathname that takes into account, as necessary, the current directory associated with its root name. \(For Posix, the functions return `absolute(pval)`.\)
+The functions return an absolute pathname that takes into account, as necessary, the current directory associated with its root name. \(For POSIX, the functions return `absolute(pval)`.\)
 
 ## <a name="temp_directory_path"></a> temp_directory_path
 
diff --git a/docs/standard-library/filesystem.md b/docs/standard-library/filesystem.md
@@ -19,19 +19,19 @@ using namespace std::experimental::filesystem::v1;
 > [!IMPORTANT]
 > As of the release of Visual Studio 2017, the \<filesystem> header was not yet a C++ standard. C++ in Visual Studio 2017 (MSVC v141) implements the final draft standard, found in [ISO/IEC JTC 1/SC 22/WG 21 N4100](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4100.pdf).
 
-This header supports filesystems for one of two broad classes of host operating systems: Microsoft Windows and Posix.
+This header supports filesystems for one of two broad classes of host operating systems: Microsoft Windows and POSIX.
 
 While most functionality is common to both operating systems, this document identifies where differences occur. For example:
 
 - Windows supports multiple root names, such as c: or \\\network_name. A filesystem consists of a forest of trees, each with its own root directory, such as c:\ or \\\network_name\\, and each with its own current directory, for completing a relative pathname (one that is not an absolute pathname).
 
-- Posix supports a single tree, with no root name, the single root directory /, and a single current directory.
+- POSIX supports a single tree, with no root name, the single root directory /, and a single current directory.
 
 Another significant difference is the native representation of pathnames:
 
 - Windows uses a null-terminated sequence of wchar_t, encoded as UTF-16 (one or two elements for each character).
 
-- Posix uses a null-terminated sequence of char, encoded as UTF-8 (one or more elements for each character).
+- POSIX uses a null-terminated sequence of char, encoded as UTF-8 (one or more elements for each character).
 
 - An object of class path stores the pathname in native form, but supports easy conversion between this stored form and several external forms:
 
@@ -51,7 +51,7 @@ Another difference is the detail with which each operating system lets you speci
 
 1. Windows records whether a file is read only or writable, an attribute that has no meaning for directories.
 
-1. Posix records whether a file can be read, written, or executed (scanned if a directory), by the owner, by the owner's group, or by everybody, plus a few other permissions.
+1. POSIX records whether a file can be read, written, or executed (scanned if a directory), by the owner, by the owner's group, or by everybody, plus a few other permissions.
 
 Common to both systems is the structure imposed on a pathname once you get past the root name. For the pathname c:/abc/xyz/def.ext:
 
diff --git a/docs/standard-library/locale-class.md b/docs/standard-library/locale-class.md
@@ -85,7 +85,7 @@ messages<char>
 messages<wchar_t>
 ```
 
-(The last category is required by Posix, but not the C Standard.)
+(The last category is required by POSIX, but not the C Standard.)
 
 Some of these predefined facets are used by the `iostream` classes, to control the conversion of numeric values to and from text sequences.
 
@@ -193,7 +193,7 @@ The type is a synonym for an **int** type that can represent a group of distinct
 
 - `time`, corresponding to the C category LC_TIME
 
-- `messages`, corresponding to the Posix category LC_MESSAGES
+- `messages`, corresponding to the POSIX category LC_MESSAGES
 
 Two more useful values are:
 
diff --git a/docs/standard-library/path-class.md b/docs/standard-library/path-class.md
@@ -58,7 +58,7 @@ class path;
 |[has_root_name](#has_root_name)|Returns `!root_name().empty()`.|
 |[has_root_path](#has_root_path)|Returns `!root_path().empty()`.|
 |[has_stem](#has_stem)|Returns `!stem().empty()`.|
-|[is_absolute](#is_absolute)|For Windows, the function returns `has_root_name() && has_root_directory()`. For Posix, the function returns `has_root_directory()`.|
+|[is_absolute](#is_absolute)|For Windows, the function returns `has_root_name() && has_root_directory()`. For POSIX, the function returns `has_root_directory()`.|
 |[is_relative](#is_relative)|Returns `!is_absolute()`.|
 |[make_preferred](#make_preferred)|Converts each separator to a preferred_separator as needed.|
 |[native](#native)|Returns `myname`.|
@@ -369,7 +369,7 @@ bool has_stem() const;
 
 ## <a name="is_absolute"></a> path::is_absolute
 
-For Windows, the function returns `has_root_name() && has_root_directory()`. For Posix, the function returns `has_root_directory()`.
+For Windows, the function returns `has_root_name() && has_root_directory()`. For POSIX, the function returns `has_root_directory()`.
 
 ```cpp
 bool is_absolute() const;
@@ -626,7 +626,7 @@ The constant object gives the preferred character for separating path components
 ```cpp
 #if _WIN32_C_LIB
 static constexpr value_type preferred_separator == L'\\';
-#else // assume Posix
+#else // assume POSIX
 static constexpr value_type preferred_separator == '/';
 #endif // filesystem model now defined
 ```
@@ -815,7 +815,7 @@ The type describes the `path` elements favored by the host operating system.
 ```cpp
 #if _WIN32_C_LIB
 typedef wchar_t value_type;
-#else // assume Posix
+#else // assume POSIX
 typedef char value_type;
 #endif // filesystem model now defined
 ```
diff --git a/docs/standard-library/system-error-enums.md b/docs/standard-library/system-error-enums.md
@@ -8,7 +8,7 @@ ms.assetid: b21321b7-404a-40de-8777-a85b77c6fa58
 
 ## <a name="errc"></a> errc
 
-Provides symbolic names for all the error-code macros defined by Posix in `<errno.h>`.
+Provides symbolic names for all the error-code macros defined by POSIX in `<errno.h>`.
 
 ```
 class errc {
diff --git a/docs/standard-library/system-error.md b/docs/standard-library/system-error.md
@@ -46,7 +46,7 @@ Include the header \<system_error> to define the exception class `system_error`
 
 |||
 |-|-|
-|[errc](../standard-library/system-error-enums.md#errc)|Provides symbolic names for all the error-code macros defined by Posix in `<errno.h>`.|
+|[errc](../standard-library/system-error-enums.md#errc)|Provides symbolic names for all the error-code macros defined by POSIX in `<errno.h>`.|
 
 ### Classes and Structs
 
diff --git a/docs/text/string-and-i-o-formatting-modern-cpp.md b/docs/text/string-and-i-o-formatting-modern-cpp.md
@@ -45,7 +45,7 @@ Some advantages of `Boost.Format` are:
 
 - Extensible: Works for any type that can be streamed.
 
-- Convenient: Standard Posix and similar format strings.
+- Convenient: Standard POSIX and similar format strings.
 
 Although `Boost.Format` is built on C++ [\<iostream>](../standard-library/iostream-programming.md) facilities, which are safe and extensible, they aren't performance-optimized. When you require performance optimization, consider C [printf](../c-runtime-library/reference/printf-printf-l-wprintf-wprintf-l.md) and [sprintf](../c-runtime-library/reference/sprintf-sprintf-l-swprintf-swprintf-l-swprintf-l.md), which are fast and easy to use. However, they aren't extensible or safe from vulnerabilities. (Safe versions exist, but they incur a slight performance penalty. For more information, see [printf_s, _printf_s_l, wprintf_s, _wprintf_s_l](../c-runtime-library/reference/printf-s-printf-s-l-wprintf-s-wprintf-s-l.md) and [sprintf_s, _sprintf_s_l, swprintf_s, _swprintf_s_l](../c-runtime-library/reference/sprintf-s-sprintf-s-l-swprintf-s-swprintf-s-l.md)).
 
