You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/build/cmakesettings-reference.md
+3-18Lines changed: 3 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,11 +27,11 @@ A `configuration` has these properties:
27
27
-`addressSDanitizerEnabled`: if `true` compiles the program with Address Sanitizer (Experimental on Windows). On Linux, compile with -fno-omit-frame-pointer and compiler optimization level -Os or -Oo for best results.
28
28
-`addressSanitizerRuntimeFlags`: runtime flags passed to AddressSanitizer via the ASAN_OPTIONS environment variable. Format: flag1=value:flag2=value2.
29
29
-`buildCommandArgs`: specifies native build switches passed to CMake after --build --. For example, passing -v when using the Ninja generator forces Ninja to output command lines. See [Ninja command line arguments](#ninja) for more information on Ninja commands.
30
-
-`buildRoot`: specifies the directory in which CMake generates build scripts for the chosen generator. Maps to **-DCMAKE_BINARY_DIR** switch and specifies where the CMake cache will be created. If the folder does not exist, it is created. Supported macros include `${workspaceRoot}`, `${workspaceHash}`, `${projectFile}`, `${projectDir}`, `${thisFile}`, `${thisFileDir}`, `${name}`, `${generator}`, and`${env.VARIABLE}`.
30
+
-`buildRoot`: specifies the directory in which CMake generates build scripts for the chosen generator. Maps to **-DCMAKE_BINARY_DIR** switch and specifies where *CMakeCache.txt*will be created. If the folder does not exist, it is created. Supported macros include `${workspaceRoot}`, `${workspaceHash}`, `${projectFile}`, `${projectDir}`, `${thisFile}`, `${thisFileDir}`, `${name}`, `${generator}`, `${env.VARIABLE}`.
31
31
-`cacheGenerationCommand`: specifies a command line tool and arguments, for example *gencache.bat debug* to generate the cache. The command is run from the shell in the specified environment for the configuration when the user explicity requests regeneration, or a CMakeLists.txt or CMakeSettings.json file is modified.
32
-
-`cacheRoot`: specifies the path to a CMake cache. This directory should contain an existing CMakeCache.txt file.
32
+
-`cacheRoot`: specifies the path to a CMake cache. This directory should contain an existing *CMakeCache.txt* file.
33
33
-`clangTidyChecks`: comma-separated list of warnigns which will be passed to clang-tidy; wildcards are allowed and '-' prefix will remove checks.
34
-
-`cmakeCommandArgs`: specifies additional command-line options passed to CMake when invoked to generate the cache.
34
+
-`cmakeCommandArgs`: specifies additional command-line options passed to CMake when invoked to generate the project files.
35
35
-`cmakeToolchain`: specifies the toolchain file. This is passed to CMake using -DCMAKE_TOOLCHAIN_FILE."
36
36
-`codeAnalysisRuleset`: specifies the ruleset to use when running code analysis. This can be a full path or the file name of a ruleset file installed by Visual Studio.
37
37
-`configurationType`: specifies the build type configuration for the selected generator. May be one of:
@@ -74,22 +74,8 @@ When the active configuration specifies a Visual Studio generator, by default MS
-`configurationType`: specifies the build type configuration for the selected generator. May be one of:
78
-
79
-
- Debug
80
-
- Release
81
-
- MinSizeRel
82
-
- RelWithDebInfo
83
-
84
-
-`buildRoot`: specifies the directory in which CMake generates build scripts for the chosen generator. Maps to **-DCMAKE_BINARY_DIR** switch and specifies where the *CMakeCache.txt* will be created. If the folder does not exist, it is created.Supported macros include `${workspaceRoot}`, `${workspaceHash}`, `${projectFile}`, `${projectDir}`, `${thisFile}`, `${thisFileDir}`, `${name}`, `${generator}`, `${env.VARIABLE}`.
85
77
-`installRoot`: specifies the directory in which CMake generates install targets for the chosen generator. Supported macros include `${workspaceRoot}`, `${workspaceHash}`, `${projectFile}`, `${projectDir}`, `${thisFile}`, `${thisFileDir}`, `${name}`, `${generator}`, `${env.VARIABLE}`.
86
-
-`cmakeCommandArgs`: specifies additional command-line options passed to CMake when invoked to generate the project files.
87
-
-`cmakeToolchain`: specifies the toolchain file. This is passed to CMake using -DCMAKE_TOOLCHAIN_FILE."
88
-
-`buildCommandArgs`: specifies native build switches passed to CMake after --build --. For example, passing -v when using the Ninja generator forces Ninja to output command lines. See [Ninja command line arguments](#ninja) for more information on Ninja commands.
89
-
-`ctestCommandArgs`: specifies additional command-line options passed to CTest when running the tests."
90
-
-`codeAnalysisRuleset`: specifies the ruleset to use when running code analysis. This can be a full path or the file name of a ruleset file installed by Visual Studio.
91
78
-`inheritEnvironments`: specifies one or more compiler environments that this configuration depends on. May be any custom environment or one of the predefined environments. For more information, see [Environments](#environments).
92
-
-`installRoot`: specifies the directory in which CMake generates install targets for the chosen generator. Supported macros include `${workspaceRoot}`, `${workspaceHash}`, `${projectFile}`, `${projectDir}`, `${thisFile}`, `${thisFileDir}`, `${name}`, `${generator}`, `${env.VARIABLE}`.
93
79
-`intelliSenseMode`: specifies the mode used for computing intellisense information". May be one of:
94
80
95
81
- windows-msvc-x86
@@ -112,7 +98,6 @@ When the active configuration specifies a Visual Studio generator, by default MS
112
98
- linux-gcc-x64
113
99
- linux-gcc-arm"
114
100
115
-
-`cacheRoot`: specifies the path to a CMake cache. This directory should contain an existing *CMakeCache.txt* file.
116
101
-`name`: names the configuration. See [CMake predefined configuration reference](cmake-predefined-configuration-reference.md) for more information about the pre-defined configurations.
117
102
-`wslPath`: the path to the launcher of an instance of Windows Subsystem for Linux.
Copy file name to clipboardExpand all lines: docs/build/reference/common-macros-for-build-commands-and-properties.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -51,7 +51,7 @@ This table describes a commonly used subset of the available macros; there are m
51
51
|**$(TargetPath)**|The absolute path name of the primary output file for the build (defined as drive + path + base name + file extension).|
52
52
|**$(VCInstallDir)**|The directory that contains the C++ content of your Visual Studio installation. This property contains the version of the targeted Microsoft C++ (MSVC) toolset, which might be different that the host Visual Studio. For example, when building with `$(PlatformToolset) = v140`, **$(VCInstallDir)** contains the path to the Visual Studio 2015 installation.|
53
53
|**$(VSInstallDir)**|The directory into which you installed Visual Studio. This property contains the version of the targeted Visual Studio toolset, which might be different that the host Visual Studio. For example, when building with `$(PlatformToolset) = v110`, **$(VSInstallDir)** contains the path to the Visual Studio 2012 installation.|
54
-
|**$(WebDeployPath)**|The relative path from the web deployment root to where the project outputs belong. Returns the same value as <xref:Microsoft.VisualStudio.VCProjectEngine.VCWebDeploymentTool.RelativePath%2A>.|
54
+
|**$(WebDeployPath)**|The relative path from the web deployment root to where the project outputs belong.|
55
55
|**$(WebDeployRoot)**|The absolute path to the location of **\<localhost>**. For example, c:\inetpub\wwwroot.|
Copy file name to clipboardExpand all lines: docs/c-runtime-library/compatibility.md
+8-7Lines changed: 8 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,27 +1,28 @@
1
1
---
2
2
title: "Compatibility"
3
-
ms.date: "11/04/2016"
3
+
description: "Describes the compatibility of the Microsoft Universal C runtime library (UCRT) with the Standard C library, POSIX, the Safe CRT, and Store apps."
4
+
ms.date: "12/06/2019"
4
5
f1_keywords: ["c.programs"]
5
6
helpviewer_keywords: ["CRT, compatibility", "compatibility, C run-time libraries", "compatibility"]
6
7
ms.assetid: 346709cb-edda-4909-9a19-3d253eddb6b7
7
8
---
8
9
# Compatibility
9
10
10
-
The Universal C Run-Time Library (UCRT) supports most of the C standard library required for C++ conformance. It implements the C99 (ISO/IEC 9899:1999) library, with the exceptions of the type-generic macros defined in \<tgmath.h>, and strict type compatibility in \<complex.h>. The UCRT also implements a large subset of the POSIX.1 (ISO/IEC 9945-1:1996, the POSIX System Application Program Interface) C library, but is not fully conformant to any specific POSIX standard. In addition, the UCRT implements several Microsoft-specific functions and macros that are not part of a standard.
11
+
The Universal C Run-Time Library (UCRT) supports most of the C standard library required for C++ conformance. It implements the C99 (ISO/IEC 9899:1999) library, with certain exceptions: The type-generic macros defined in \<tgmath.h>, and strict type compatibility in \<complex.h>. The UCRT also implements a large subset of the POSIX.1 (ISO/IEC 9945-1:1996, the POSIX System Application Program Interface) C library. However, it's not fully conformant to any specific POSIX standard. The UCRT also implements several Microsoft-specific functions and macros that aren't part of a standard.
11
12
12
-
Functions specific to the Microsoft implementation of Visual C++ are found in the vcruntime library. Many of these functions are for internal use and cannot be called by user code. Some are documented for use in debugging and implementation compatibility.
13
+
Functions specific to the Microsoft implementation of Visual C++ are found in the vcruntime library. Many of these functions are for internal use and can't be called by user code. Some are documented for use in debugging and implementation compatibility.
13
14
14
-
The C++ standard reserves names that begin with an underscore in the global namespace to the implementation. Because the POSIX functions are in the global namespace, but are not part of the standard C runtime library, the Microsoft-specific implementations of these functions have a leading underscore. For portability, the UCRT also supports the default names, but the Microsoft C++ compiler issues a deprecation warning when code that uses them is compiled. Only the default POSIX names are deprecated, not the functions. To suppress the warning, define `_CRT_NONSTDC_NO_WARNINGS` before including any headers in code that uses the original POSIX names.
15
+
The C++ standard reserves names that begin with an underscore in the global namespace to the implementation. Both the POSIX functions and Microsoft-specific runtime library functions are in the global namespace, but aren't part of the standard C runtime library. That's why the preferred Microsoft implementations of these functions have a leading underscore. For portability, the UCRT also supports the default names, but the Microsoft C++ compiler issues a deprecation warning when code that uses them is compiled. Only the default names are deprecated, not the functions themselves. To suppress the warning, define `_CRT_NONSTDC_NO_WARNINGS` before including any headers in code that uses the original POSIX names.
15
16
16
-
Certain functions in the standard C library have a history of unsafe usage, because of misused parameters and unchecked buffers. These functions are often the source of security issues in code. Microsoft created a set of safer versions of these functions that verify parameter usage and invoke the invalid parameter handler when an issue is detected at runtime. By default, the Microsoft C++ compiler issues a deprecation warning when a function is used that has a safer variant available. When you compile your code as C++, you can define `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` as 1 to eliminate most warnings. This uses template overloads to call the safer variants while maintaining portable source code. To suppress the warning, define `_CRT_SECURE_NO_WARNINGS` before including any headers in code that uses these functions. For more information, see [Security Features in the CRT](../c-runtime-library/security-features-in-the-crt.md).
17
+
Certain functions in the standard C library have a history of unsafe usage, because of misused parameters and unchecked buffers. These functions are often the source of security issues in code. Microsoft created a set of safer versions of these functions that verify parameter usage. They invoke the invalid parameter handler when an issue is detected at runtime. By default, the Microsoft C++ compiler issues a deprecation warning when a function is used that has a safer variant available. When you compile your code as C++, you can define `_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES` as 1 to eliminate most warnings. This macro enables template overloads to call the safer variants while maintaining portable source code. To suppress the warning, define `_CRT_SECURE_NO_WARNINGS` before including any headers in code that uses these functions. For more information, see [Security Features in the CRT](../c-runtime-library/security-features-in-the-crt.md).
17
18
18
-
Except as noted within the documentation for specific functions, the UCRT is compatible with the Windows API. Certain functions are not supported in Windows 8 Store apps or in Universal Windows Platform (UWP) apps on Windows 10. These functions are listed in [CRT functions not supported in Universal Windows Platform apps](../cppcx/crt-functions-not-supported-in-universal-windows-platform-apps.md), which enumerates the functions not supported by the Windows Runtime and [UWP](/uwp).
19
+
Except as noted within the documentation for specific functions, the UCRT is compatible with the Windows API. Certain functions aren't supported in Windows Store or Universal Windows Platform ([UWP](/uwp)) apps. These functions are listed in [CRT functions not supported in Universal Windows Platform apps](../cppcx/crt-functions-not-supported-in-universal-windows-platform-apps.md).
19
20
20
21
## Related Articles
21
22
22
23
|Title|Description|
23
24
|-----------|-----------------|
24
-
|[UWP Apps, the Windows Runtime, and the C Run-Time](../c-runtime-library/windows-store-apps-the-windows-runtime-and-the-c-run-time.md)|Describes when UCRT routines are not compatible with Universal Windows apps or Microsoft Store apps.|
25
+
|[UWP Apps, the Windows Runtime, and the C Run-Time](../c-runtime-library/windows-store-apps-the-windows-runtime-and-the-c-run-time.md)|Describes when UCRT routines aren't compatible with Universal Windows apps or Microsoft Store apps.|
25
26
|[ANSI C Compliance](../c-runtime-library/ansi-c-compliance.md)|Describes standard-compliant naming in the UCRT.|
26
27
|[UNIX](../c-runtime-library/unix.md)|Provides guidelines for porting programs to UNIX.|
27
28
|[Windows Platforms (CRT)](../c-runtime-library/windows-platforms-crt.md)|Lists the operating systems that are the CRT supports.|
Inputs, from a port, a byte (`_inp`), a word (`_inpw`), or a double word (`_inpd`).
15
+
Inputs, from a port, a byte (`inp`, `_inp`), a word (`inpw`, `_inpw`), or a double word (`_inpd`).
15
16
16
17
> [!IMPORTANT]
17
-
> These functions are obsolete. Beginning in Visual Studio 2015, they are not available in the CRT.
18
-
19
-
> [!IMPORTANT]
20
-
> 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).
18
+
> These functions are obsolete. Beginning in Visual Studio 2015, they are not available in the CRT.
19
+
> 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).
21
20
22
21
## Syntax
23
22
24
-
```
23
+
```cpp
25
24
int_inp(
26
25
unsigned short port
27
26
);
@@ -33,9 +32,9 @@ unsigned long _inpd(
33
32
);
34
33
```
35
34
36
-
####Parameters
35
+
### Parameters
37
36
38
-
*port*<br/>
37
+
*port*\
39
38
I/O port number.
40
39
41
40
## Return Value
@@ -48,6 +47,8 @@ The `_inp`, `_inpw`, and `_inpd` functions read a byte, a word, and a double wor
48
47
49
48
Because these functions read directly from an I/O port, they cannot be used in user code.
50
49
50
+
The `inp` and `inpw` names are older, deprecated names for the `_inp` and `_inpw` functions. For more information, see [POSIX function names](../error-messages/compiler-warnings/compiler-warning-level-3-c4996.md#posix-function-names).
51
+
51
52
## Requirements
52
53
53
54
|Routine|Required header|
@@ -64,5 +65,5 @@ All versions of the [C run-time libraries](../c-runtime-library/crt-library-feat
64
65
65
66
## See also
66
67
67
-
[Console and Port I/O](../c-runtime-library/console-and-port-i-o.md)<br/>
0 commit comments