C99 library support in Visual Studio 2013

C99 library support in Visual Studio 2013

Rate This
  • Comments 26

Hello, I’m Pat Brenner, a developer on the Visual C++ Libraries team. In this blog post I want to share some information about the C99 support added to the C run-time library in Visual Studio 2013.

To summarize, we added declarations and implementations for missing functions in the following headers: math.h, ctype.h, wctype.h, stdio.h, stdlib.h, and wchar.h. We also added the new headers complex.h, stdbool.h, fenv.h, and inttypes.h, and added the implementations for all the functions declared in them. In addition, we added the new C++ wrapper headers (ccomplex, cfenv, cinttypes, ctgmath) and updated a number of others (ccomplex, cctype, clocale, cmath, cstdint, cstdio, cstring, cwchar, and cwctype).

Most of this work (all the C headers except stdbool.h and fenv.h) was done in time for the Visual Studio 2013 Preview release and is available with it, but the remainder (stdbool.h, fenv.h and the C++ wrapper headers) has been done for Visual Studio 2013 RTM and will be available with that release.

In more detail, these are the declarations and implementations we added, grouped by the headers that declare them:

  • math.h: 
    • float_t, double_t, fpclassify, isfinite isinf, isnan, isnormal, signbit
    • HUGE_VALF, HUGE_VALL, INFINITY, NAN, MATH_ERRNO, MATH_ERREXCEPT
    • FP_INFINITE, FP_NAN, FP_NORMAL, FP_SUBNORMAL, FP_ZERO, FP_ILOGB0, FP_ILOGBNAN
    • acosh, acoshf, acoshl, asinh, asinhf, asinhl, atanh, atanhf, atanhl
    • exp2, exp2f, exp2l, expm1, expm1f, expm1l
    • ilogb, ilogbf, ilogbl, logb, logbf, logbl, log1p, log1pf, log1pl, log2, log2f, log2l
    • scalbn, scalbnf, scalbnl, scalbln, scalblnf, scalblnl
    • cbrt, cbrtf, cbrtl, erf, erff, erfl, erfc, erfcf, erfcl
    • lgamma, lgammaf, lgammal, tgamma, tgammaf, tgammal
    • nearbyint, nearbyintf, nearbyintl, nan, nanf, nanl
    • rint, rintf, rintl, lrint, lrintf, lrintl, llrint, llrintf, llrintl
    • round, roundf, roundl, lround, lroundf, lroundl, llround, llroundf, llroundl
    • trunc, truncf, truncl, remainder, remainderf, remainder, remquo, remquof, remquol
    • nextafter, nextafterf, nextafterl, nexttoward, nexttowardf, nexttowardl
    • fdim, fdimf, fdiml, fmax, fmaxf, fmaxl, fmin, fminf, fminl, fma, fmaf, fmal
  • complex.h: 
    • cacos, cacosf, cacosl, casin, casinf, casinl, catan, catanf, catanl
    • ccos, ccosf, ccosl, csin, csinf, csinl, ctan, ctanf, ctanl
    • cacosh, cacoshf, cacoshl, casinh, casinhf, casinhl, catanh, catanhf, catanhl
    • ccosh, ccoshf, ccoshl, csinh, csinhf, csinhl, ctanh, ctanhf, ctanhl
    • cexp, cexpf, cexpl, clog, clogf, clogl, cabs, cabsf, cabsl
    • cpow, cpowf, cpowl, csqrt, csqrtf, csqrtl, carg, cargf, cargl
    • cimag, cimagf, cimagl, conj, conjf, conjl, cproj, cprojf, cprojl, creal, crealf, creall
  • fenv.h: 
    • fegetenv, fesetenv, feupdateenv, fegetexceptflag, fesetexceptflag
    • feclearexcept, feholdexcept, fetestexcept, feraiseexcept
  • inttypes.h:
    • PRIi8, PRIi16, PRIi32, PRIi64, PRIiMAX, PRIiPTR, PRIiLEAST8, PRIiLEAST16, PRIiLEAST32, PRIiLEAST64, PRIiFAST8, PRIiFAST16, PRIiFAST32, PRIiFAST64
    • PRIo8, PRIo16, PRIo32, PRIo64, PRIoMAX, PRIoPTR, PRIoLEAST8, PRIoLEAST16, PRIoLEAST32, PRIoLEAST64, PRIoFAST8, PRIoFAST16, PRIoFAST32, PRIoFAST64
    • PRIu8, PRIu16, PRIu32, PRIu64, PRIuMAX, PRIuPTR, PRIuLEAST8, PRIuLEAST16, PRIuLEAST32, PRIuLEAST64, PRIuFAST8, PRIuFAST16, PRIuFAST32, PRIuFAST64
    • PRIx8, PRIx16, PRIx32, PRIx64, PRIxMAX, PRIxPTR, PRIxLEAST8, PRIxLEAST16, PRIxLEAST32, PRIxLEAST64, PRIxFAST8, PRIxFAST16, PRIxFAST32, PRIxFAST64
    • PRIX8, PRIX16, PRIX32, PRIX64, PRIXMAX, PRIXPTR, PRIXLEAST8, PRIXLEAST16, PRIXLEAST32, PRIXLEAST64, PRIXFAST8, PRIXFAST16, PRIXFAST32, PRIXFAST64
    • SCNd8, SCNd16, SCNd32, SCNd64, SCNdMAX, SCNdPTR, SCNdLEAST8, SCNdLEAST16, SCNdLEAST32, SCNdLEAST64, SCNdFAST8, SCNdFAST16, SCNdFAST32, SCNdFAST64
    • SCNi8, SCNi16, SCNi32, SCNi64, SCNiMAX, SCNiPTR, SCNiLEAST8, SCNiLEAST16, SCNiLEAST32, SCNiLEAST64, SCNiFAST8, SCNiFAST16, SCNiFAST32, SCNiFAST64
    • SCNo8, SCNo16, SCNo32, SCNo64, SCNoMAX, SCNoPTR, SCNoLEAST8, SCNoLEAST16, SCNoLEAST32, SCNoLEAST64, SCNoFAST8, SCNoFAST16, SCNoFAST32, SCNoFAST64
    • SCNu8, SCNu16, SCNu32, SCNu64, SCNuMAX, SCNuPTR, SCNuLEAST8, SCNuLEAST16, SCNuLEAST32, SCNuLEAST64, SCNuFAST8, SCNuFAST16, SCNuFAST32, SCNuFAST64
    • SCNx8, SCNx16, SCNx32, SCNx64, SCNxMAX, SCNxPTR, SCNxLEAST8, SCNxLEAST16, SCNxLEAST32, SCNxLEAST64, SCNxFAST8, SCNxFAST16, SCNxFAST32, SCNxFAST64
    • SCNX8, SCNX16, SCNX32, SCNX64, SCNXMAX, SCNXPTR, SCNXLEAST8, SCNXLEAST16, SCNXLEAST32, SCNXLEAST64, SCNXFAST8, SCNXFAST16, SCNXFAST32, SCNXFAST64
    • imaxabs, imaxdiv, strtoimax, strtoumax, wcstoimax, wcstoumax
  • ctype.h
    • isblank
  • wctype.h
    • iswblank
  • float.h
    • DECIMAL_DIG, FLT_EVAL_METHOD
  • stdarg.h
    • va_copy
  • stdbool.h
    • bool, true, false, __bool_true_false_are_defined
  • stdio.h
    • vscanf, vfscanf, vsscanf
  • stdlib.h
    • atoll, strtof, strtold, strtoll, strtoull
  • wchar.h
    • vwscanf, vfwscanf, vswscanf, wcstof, wcstold, wcstoll, wcstoull

We know that this is not complete support for the C99 library functions. To the best of our understanding, the missing pieces are these:

  • The tgmath.h header is missing. C compiler support is needed for this header.
    • Note that the ctgmath header was added—this is possible because that header does not require the tgmath.h header—only the ccomplex and cmath headers.
  • The uchar.h header is missing. This is from the C Unicode TR.
  • Several format specifiers in the printf family are not yet supported.
  • The snprintf and snwprintf functions are missing from stdio.h and wchar.h.

I hope you find this information useful. We did all that we had time for, while trying to prioritize those functions we thought most important.

Pat Brenner, Visual C++ Libraries Development Team

  • @Wesley Robb: be careful with that assumption - there are language differences in C99 that cannot be addressed by the library.  For example, C99 supports declarations mixed with executable statements, variable length arrays, and designated initializers.  The library can't add support for those things, and this announcement doesn't say that MS is adding C99 features to the C compiler.

    So - this announcement is really good news. But I don't think you should read it as meaning you'll be able to take any C99 program and compile it without trouble. If the only problems are just about declarations mixed with statements, you might be able to get away with compiling the code as C++.

    I really wish that C99 standard `snprint()`/`snwprintf()` were part of this announcement.

  • Michael Burr: We announced that C99 _Bool, compound literals, designated initializers, and variable declarations will be implemented in VS 2013 RTM. See blogs.msdn.com/.../c-11-14-stl-features-fixes-and-breaking-changes-in-vs-2013.aspx . That's not the entire C99 Core Language, but it's more than zero.

    We don't hate snprintf() (quite the contrary), we just missed it and ran out of time. Unfortunately, _snprintf()'s semantics are totally different, so we can't just alias them like we did for a number of other C99 functions (especially the long long family). The necessary machinery is lurking in _scprintf so it shouldn't be too hard to add post-2013-RTM (said the non-CRT-maintainer).

  • Stephan: apparently I need to do some catching up on vcblog.  That's good news about the C99 core language updates.

  • Our E-XD++ HMI & SCADA Visualization source code kit is builded with Visual C++ 6.0 for many years, if this visual studio 2013 can works with Windows XP, that will be very very useful for all Visual c++ engineers.

    The end, thanks for your great work.

    Jackie

    CTO of UCanCode Software

    http://www.ucancode.net

  • @Good news,

    There is a difference in interpretation of "XP support":

    "run on XP" vs "build for XP"

    VS2012 can't run on XP but you can compile for XP.

    Hopefully VS2013 RTM, they would provide the "build for XP" support. Right now I don't they have it!

  • @Morty, you can also target XP with VS 2013 as well.

  • Other compilers use the terminology of "build", "host", and "target" platforms. The "build" platform is used to build the compiler itself. MS builds VC, so you don't care about this one. The "host" platform is used by the developer to run the compiler. The "target" platform is used by the end user to run the compiler's output.

  • 27>------ Build started: Project: yoho, Configuration: Debug Win32 ------

    Let the Battle of Bad Semantics begin!

  • Stephan T. Lavavej - MSFT: "It also leads to user headaches (consider what happens if users try to link code compiled with different modes)"

    That's going out of your way to make it hard. You generally won't mix and match standards within the same project. It's going to be a common compiler flag shared across your project.

  • "That's going out of your way to make it hard. You generally won't mix and match standards within the same project. It's going to be a common compiler flag shared across your project."

    That doesn't help with binary-only third-party components.

  • Well, I'm glad that you all finally started work on C99 compatibility. I hope that by C++2014, you'll get up to speed for c too. You could probably save on the work by fast forwarding to C11. C11 made several C99 features such as VLA's optional. And tgmath.h can be easily implemented if you have the the C11 _Generic keyword. Anyways, thanks for the good work and keep it up.

Page 2 of 2 (26 items) 12