{"id":523,"date":"2014-06-18T14:00:00","date_gmt":"2014-06-18T14:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vcblog\/2014\/06\/18\/c-runtime-crt-features-fixes-and-breaking-changes-in-visual-studio-14-ctp1\/"},"modified":"2019-02-18T18:05:20","modified_gmt":"2019-02-18T18:05:20","slug":"c-runtime-crt-features-fixes-and-breaking-changes-in-visual-studio-14-ctp1","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/c-runtime-crt-features-fixes-and-breaking-changes-in-visual-studio-14-ctp1\/","title":{"rendered":"C Runtime (CRT) Features, Fixes, and Breaking Changes in Visual Studio 14 CTP1"},"content":{"rendered":"

(This is the second of two articles on changes to the C Runtime (CRT) in the Visual Studio “14” CTP. The first article, The Great C Runtime (CRT) Refactoring<\/a>, covered the major architectural changes to the CRT; this second article enumerates the new features, bug fixes, and breaking changes.)<\/em><\/p>\n

This list covers all of the major changes to the CRT that were made after the Visual Studio 2013 RTM and which are present in the Visual Studio “14” CTP. For a similar list covering changes to the C++ Standard Library, see Stephan’s article from June 6, C++14 STL Features, Fixes, And Breaking Changes In Visual Studio 2014<\/a>. The changes are grouped by the main CRT header with which they are associated, with one large change to the printf<\/code> and scanf<\/code> functions covered first.<\/p>\n

In the Visual Studio “14” CTP we have fully implemented the C99 Standard Library, with the exception of any library features that depend on compiler features not yet supported by the Visual C++ compiler (notably, <tgmath.h><\/code> is not implemented). There are undoubtedly some remaining conformance issues–we know of a few, including that _Exit<\/code> is missing and wcstok<\/code> has the wrong signature, and we are working to fix these. If you find a bug or a missing feature, please do report it on Microsoft Connect<\/a>. If you report bugs now, there is a very good chance that we’ll be able to fix them before RTM.<\/p>\n

Please note that the documentation on MSDN has not yet been updated to include any of the changes covered in these blog posts.<\/p>\n

Fixing the Wide String Format and Conversion Specifiers<\/h3>\n

Updated April 7, 2015:  This feature was reverted in Visual Studio 2015 CTP6; it will not be present in Visual Studio 2015.  We had many customers express concern about this change and we discovered several new issues when working with static libraries.<\/span><\/span><\/strong><\/p>\n

The biggest “breaking change” to the CRT in the Visual Studio “14” CTP is a change to how the wide string formatted I\/O functions (e.g., wprintf<\/code> and wscanf<\/code>) handle the %c<\/code>, %s<\/code>, and %[]<\/code> (scanset) format and conversion specifiers.<\/span><\/p>\n

The wide string formatted I\/O functions were first implemented in the Visual C++ CRT in the early 1990s. They were implemented such that the %c<\/code>, %s<\/code>, and %[]<\/code> specifiers mapped to a wide character or string argument. For example, this was the behavior (and remained the behavior through Visual C++ 2013):<\/span><\/p>\n

 printf(\"Hello, %s!\\n\", \"World\"); \/\/ Lowercase s: narrow string printf(\"Hello, %S!\\n\", L\"World\"); \/\/ Capital S: wide string wprintf(L\"Hello, %s!\\n\", L\"World\"); \/\/ Lowercase s: wide string wprintf(L\"Hello, %S!\\n\", \"World\"); \/\/ Capital S: narrow string <\/span><\/pre>\n
This design has the advantage that the %c<\/code>, %s<\/code>, and %[]<\/code> specifiers always map to an argument of the “natural” width for the function call. If you’re calling a narrow string formatted I\/O function, they map to a narrow character or string argument; if you’re calling a wide string formatted I\/O function, they map to a wide character or string argument. Among other things, this design made it easier to move from use of narrow strings to use of wide strings, via the macros in <tchar.h><\/code>.<\/span><\/p>\n
These functions were later standardized in C99, and unfortunately, the standardized behavior was different. In the C99 specification, the %c<\/code>, %s<\/code>, and %[]<\/code> specifiers always map to a narrow character or string argument. The l<\/code> (lowercase L) length modifier must be used to format a wide character or string argument. So, per the C99 specification, the following calls are correct:<\/span><\/p>\n
 printf(\"Hello, %s!\\n\", \"World\"); \/\/ s: narrow string printf(\"Hello, %ls!\\n\", L\"World\"); \/\/ ls: wide string wprintf(L\"Hello, %ls!\\n\", L\"World\"); \/\/ ls: wide string wprintf(L\"Hello, %s!\\n\", \"World\"); \/\/ s: narrow string <\/span><\/pre>\n
This design has the advantage that the specifiers always have the same meaning, regardless which function is called. It has the disadvantage that it doesn’t match what was previously implemented in the Visual C++ CRT and it doesn’t work with the macros in <tchar.h><\/code>.<\/span><\/p>\n
In the Visual Studio “14” CTP, we have flipped the meaning of the %c<\/code>, %s<\/code>, and %[]<\/code> specifiers for the wide formatted I\/O functions so that their behavior matches what is required by the C Standard.<\/strong> The meanings of the capital letter specifier equivalents (%C<\/code> and %S<\/code>) have also been changed, for consistency. In order to facilitate continued use of the <tchar.h><\/code> header we have also added a new length modifier, T<\/code>, that means the argument is of the “natural” width, in effect giving the legacy behavior. So, for example, all of the following calls are correct:<\/span><\/p>\n
 printf(\"Hello, %s!\\n\", \"World\"); \/\/ narrow string printf(\"Hello, %S!\\n\", L\"World\"); \/\/ wide string printf(\"Hello, %ls!\\n\", L\"World\"); \/\/ wide string printf(\"Hello, %Ts!\\n\", \"World\"); \/\/ natural width (narrow) wprintf(L\"Hello, %s!\\n\", \"World\"); \/\/ narrow string wprintf(L\"Hello, %S!\\n\", L\"World\"); \/\/ wide string wprintf(L\"Hello, %ls!\\n\", L\"World\"); \/\/ wide string wprintf(L\"Hello, %Ts!\\n\", L\"World\"); \/\/ natural width (wide) <\/span><\/pre>\n
This fairly small change has a very large effect on existing code. There are many millions of lines of code that expect the old behavior, and we recognize that we can’t just unconditionally break all of that code. While we encourage you to migrate code to use the conforming format strings mode, we are also providing a compile-time switch to enable you to revert the behavior back to the legacy mode. There are, therefore, two modes:<\/span><\/p>\n