MSVC in C mode is essentially C89 plus extensions needed to compile C++/C99-isms present in Windows SDK and DDK headers. And Microsoft seems to be mostly interested in whether the compiler is able to build NT kernel and drivers and nothing much else.
Until recently, even MSVC was C89. I believe they only added some C99 features because the C++11 standard required them (in VS2013, I believe), and full C99 support only came with VS2015.
FWIW, Microsoft hasn't made an effort to support much of C99 because almost none of their users (Windows and XBox developers) use C. I don't know any Windows or XBox programmers who uses C.
Your point is still valid: if you want to compile C99 code, MSVC is not even an option.
... in C mode, which is basically C89 (+ whatever is needed for recent C++ versions). Compiling C code in C++ mode is a common way of working around this. But MSVC is not a C compiler, it's a C++ compiler, so their unwillingness to invest in C is probably understandable.
While MSVC doesn't have full C99 support, MSVC supported most of the features that shipped in C99 that make it much less painful to develop in C quite a number of years before C99 support formally landed in other compilers. MS will probably never support full C99 because the demand isn't there, but it's certainly not ANSI C you are expected to write.
Does MSVC support C99 yet? Much less C11 or a future C2x?
Their priority has always been C++ and for some time their stance on C was basically "I guess we're willing to compile the subset of C that is valid C++."
It's not C99 compliant because that would require VLA support (which has been made optional in C11, which in turn enabled MSVC to be a C11 and C17 compiler, but not C99. Not that it matters much in practice though :)
MSVC has been essentially a C++ development environment for almost 2 decades now. Asking for C99 support is a bit like asking for objective C support. MS has made it abundantly clear that it would be unprofitable for them to add C99 support on many occasions before this.
C99 support in MSVC was still spotty until very recently. And for single-header libraries in particular it's helpful to use a style of C that can be #included directly into C++ source files without issue.
I thought MSVC added support for C99 at long last a few years ago? IIRC because it was effectively needed for a newer C++ standard, but still.
Also it's 2020, I wasn't even coding when C99 came out and I'm now a "senior" developer, whatever that means. You'll have to pry C99 from my cold, dead hands. Whatever compilers don't support it by now, I don't want to support them.
Yes, a few of the libraries I've been involved with do not want to allow C99 features into the codebase because of MSVC. This, IMO, is the main reason for wanting some C99 in MSVC -- to stop Windows from holding the rest of OSS hostage when it comes to more modern language features.
MSVC supports C11 and C17, minus the C99 stuff that was made optional in C11.
Anyway given the option, one should always favour C++ over C, if they care about secure code, which while not perfect it is much better than any C compiler will do.
MSVC only received C99 support starting in Visual Studio 2015 and even then it's only partial (but enough for us). Actually, we'll probably use anonymous structs and unions, which are technically a C11 feature, but have been supported by all the major compilers for a long time before C11.
MSVC lacks some C99 features like variable length arrays and complex numbers. There's always a work around, but wouldn't want to use that compiler for C unless I had to.
Going for C89 for a truly portable project is probably fine.
reply