ISO C Standard Update

ISO C Standard Update

Rate This
  • Comments 32

Hello!  My name is Arjun Bijanki, and I’m the test lead for the Visual C++ compiler.  I’m also Microsoft’s representative on the ISO C standard committee.  I recently returned from one of the committee’s semiannual meetings (this one was in Kona, Hawaii – tough trip! J)

These days, the committee is thinking hard about the next revision to the C standard (unofficially termed C1x, where 0<=x<=9).  At the meeting, the group discussed the charter for the next revision.  For C users, the whole document is interesting reading, but I wanted to draw your attention to the Additional Principles for C1x:

12. Trust the programmer, as a goal, is outdated in respect to the security and safety

programming communities. While it should not be totally disregarded as a facet of the

spirit of C, the C1Xversion of the C Standard should take into account that programmers

need the ability to check their work.


13. Unlike for C9X, the consensus at the London meeting was that there should be no

invention, without exception. Only those features that have a history and are in common

use by a commercial implementation should be considered. Also there must be care to

standardize these features in a way that would make the Standard and the commercial

implementation compatible.


14. Migration of an existing code base is an issue. The ability to mix and match C89,

C99, and C1X based code is a feature that should be considered for each proposal.

Migration is definitely important – I’d even call it a basic requirement -- but I find the other two principles more interesting.  #12 reflects the industry’s increased focus on security over the last 10 years, and it’s great to see the committee embracing that.  It’s not surprising, given the committee’s work on TR 24731 (Bounds-checking Interfaces, which includes most of the _s functions available in VS 2005). 

The committee has also asked compiler vendors to present their most widely used language extensions for consideration.  Features like extended attributes, and thread local storage, which are shared by multiple implementations (e.g. Visual C++ and GCC) will receive special attention.  In many cases, implementations will differ on syntax, but the underlying concepts will be similar.  As principle #13 says, the committee will strive to maintain compatibility.

Now, the Visual C++ compiler team receives the occasionally question as to why we haven’t implemented C99.  It’s really based on interest from our users.  Where we’ve received many requests for certain C99 features, we’ve tried to implement them (or analogues).  A couple examples are variadic macros, long long, __pragma, __FUNCTION__, and __restrict.  If there are other C99 features that you’d find useful in your work, let us know!  We don’t hear much from our C users, so speak up and make yourselves heard J

I should have another update from the C committee for you after the next meeting in April.

Until next time,


  • - standards compliant behavior and return value for snprintf/vsnprintf

    - mixed declarations and code

    - __func__ (the standard spelling of __FUNCTION__)

    - stdint/inttypes

    - anything that brings C and C++ closer to each other (that includes "mixed

     declarations and code", the inline keyword, the removal of implicit declaration of

     functions and maybe others that are coming for C++0x)

    The first 3 items would be enough to compile my code, i guess. I also

    appreciate what has been implemented so far :-)

    Any change to C that is incompatible with C++ is low priority in my opinion,

    but some of them may be useful to others.

  • - macroses with variable length arguments

    - stdint.h

    - inline

    - struct initializers

  • I'm a C/C++ programmer who uses Visual Studio 2003, 2005, and 2008 ("Orcas," Beta 2).

    1. Please provide <inttypes.h>, <stdint.h>, <cinttypes>, and <cstdint> immediately.

    2. Please provide decltype after that.

    3. Provide as much of C++ TR1 as you can.

    4. When providing features, prefer C++ to C wherever there is a conflict between the two languages.  (I'm thinking of bool, for example.  Bjarne Stroustrup has named many more areas of conflict.)

    Support for dubious new C language features, such as variable-length arrays in their current form, should go to the back of the queue.

  • "We don’t hear much from our C users, so speak up and make yourselves heard"

    Arjun, as technical chief in one of the biggest IT companies in my country, I can tell you we very much use Microsoft VC++ and .NET compilers for C development only, and that the Microsoft C compiler in conforming mode (/Za), has been excellent.

    However, these days I really wonder why we should continue to simulate our embedded systems under Windows, with the lack of attention MS has been showing ISO C99. This will certainly come to an end soon, when our target compilers move away from ISO C90 and C95, to ISO C99.

    So, before talking about TR 24731 and extended attributes, I would like an ISO C99 conforming mode added (without changing the /Za mode!), and please make sure we have an easy way to create a C project with the latest VS releases.

  • "Why use C at all? When in the "non-object" space, I use C++ as a "better C". So does every developer I know."

    Joe, many use Windows the and Microsoft C compilers for development targeting other platforms. FYI, there is more than GUI development for hosted systems going on, in fact, that's a small market compared to the embedded world. :)

  • I'd just like to reiterate the request for complete C99 support.

    There's a reason standards exist, and it's not so different vendors can all go create their own 'analogues'.

    If you need a few thousand more user requests to convince management that the users really do want C99 support, try Google. I get 'Results 1 - 10 of about 44,500 for "visual studio" C99'

  • MSVC 2008 does not support this code (ISO C99):

    int main()


     printf("hello world!");

     int x; // NOT SUPPORTED! WHY?

     scanf("%d", &x);

     for(int i = 0; i < 100; i++) // NOT SUPPORTED! WHY?


       printf("%d", i);



  • I would also like to see complete C99 support in

    Visual C/C++.

  • Why C99 standards compliance???? In the kernel world most cross-platform development is done in C. Unlike C++, C standards compliance (Windows excepted) is quite good across platforms.

    What were the Visual Studio developers thinking when they implemented _snprintf instead of snprintf??? Similar examples abound. I should not have to write code in this day and age of the ilk

    #ifdef _WIN32

       _sprintf( ...)


       sprintf( ...)


    Please support full C99 standards compliance.

  • It's much worse than you realize...

    char s[5];

    snprintf(s, sizeof(s), "fubar");

    With gcc: (C99 compliant)

    s = "fuba\0"

    With Micro$oft's "_snprintf"

    s = "fubar" - no string termination

    When it comes standards Micro$oft believes in the 3 "E's"....




    What they sell is pure FUD.




  • @Tom Zito:

    Yes, that's what i meant with "standards compliant behavior and return value for snprintf/vsnprintf". These functions should always '\0'-terminate the string and return the length of the complete string (even if it is truncated, it should return the length of the "would-be" string).

    That bug in snprintf should be high-priority IMHO, because it is an almost-silent nonconformance.

  • Please - at the top of your list of things to implement from C99 would be things that cannot be done in a library:

    - mixed declarations and code - already in C++

    - inline functions - already in C++

    - _Pragma() - this makes pragmas much more usable

    - varargs in macros

    - designated initializers

    Of course, standard snprintf(), stdint.h and  stdbool.h would be nice too.  But I already have alternatives for these that I can use.

  • I can only second the multiple requests for supporting C99. Especially those from Tom Zito and ikk.

    1. Please add the C99-standard headers: stdint, and stdbool are a priority.

    2. I know this request is futile, but a fully C99-compliant snprintf() function ( ) would be better than your 100% non-portable (and useless) sprintf_s().

    ...And next time, please think twice before adding things to C and C++. The two most egregious examples I know of are the fopen_s() and malloca() functions.

    1. fopen_s() offers exactly as much security as fopen(), only less portability. It's as if you guys WANT us to define _CRT_SECURE_NO_WARNINGS...

    2. malloca() is supposed to be an alloca() replacement... Which requires calling a freeing function (freea()). Did you guys even ASK yourselves about why people used alloca() in the first place? It was especially for NOT having to call a freeing function...

  • Also note that NONE of these requests require a language change: It's all about the CRT and its header files.

  • @ Tom

    > What they sell is pure FUD.

    No, _snprintf() pre-date snprintf(), and was not an attempt to implement the C99 version. Every function pre-fixed with underscore, belong to the implementation name-space, and is Microsoft-specific.

    Providing a compliant snprintf() implementation, should have been done years ago by the VS team. Really annoying thing this.

    I say, leave /Za mode unchanged, and start to implement C99 features with e.g. /Zc99 switch.

    Ignoring C99, will force more and more developers over to Linux.

Page 2 of 3 (32 items) 123