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,

Arjun