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,

Arjun

  • C++ is superset of C,so you implement C++ is OK!!

  • C++ is *not* a superset of C.

    Ref: http://david.tribble.com/text/cdiffs.htm

    I would like to see the differences minimized or at least smoothed in C1x.

  • I'd really like to see stdint.h included, it wouldn't even require language changes! :)

  • I would love to see the new struct initializer syntax (designated initializer list) which allows the initialization of struct members using names:

    struct foo {

     const char* name;

     /* ..many other members.. */

     const char* description;

    };

    struct foo my_foo = {

     .name = "bar";

     .description = "baz";

    };

    This is very useful for large dispatch tables where certain only certain overrides should be applied (sort of like virtual tables).

  • I think it's both a giant waste of time and actually bad.

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

    For the rare cases where I have to maintain "C" code, I don't want the compiler to change behavior from the "traditional" (i.e. C89.)

    Why is Microsoft even wasting a dime on this?

  • Gene, Andreas - thanks for your comments.  I'll get those on the list to consider for future implementation.  How much new C code do you write?  How big are your C codebases?

    Joe - we do have many customers who use the C language and are interested in its evolution.

  • >> I'd really like to see stdint.h included, it wouldn't even require language changes! :)

    I'd like this, too.  In the meantime, I've used a public domain (not GPL - true public domain) version by Danny Smith:  

    http://www.cs.colorado.edu/~main/cs1300/include/stdint.h

    I had to tweak that version to compile with some non VC 8 compilers.

  • C code is actually crucial, even for large C++ code bases, because as soon as you want to allow interop from different languages or even allow other people to use your software without having to use the same compiler (and switches, etc.), C is a must have.

    I'd like to see full C99 support to simplify porting between Linux/Windows ... even if a (C99-)feature is rarely used, having to work around it always means extra work. The world would be a much better place to be if every C compiler would understand the same (standard) C89/C99 (and please, let me choose which standard I want, i.e. /standard:C89, and not C89-with-MS-additions-but-not-full-C99 only), and an even better place if that would be the case for C++, too.

  • We need an updated and expanded POSIX-like standard for the standard C libraries.

  • "as soon as you want to allow interop from different languages or even allow other people to use your software without having to use the same compiler (and switches, etc.), C is a must have."

    Actually in that environment, assembly is a must-have.  The only reason C sometimes works is that compiler writers have cooperated well enough to make switches that can be used by programmers who cooperate well enough to get identical calling conventions used by both the caller and callee.  In cases where there hasn't been enough cooperation, C won't solve it for you.

    Similar to that is the way that __stdcall used to be PASCAL.  The way it looked, Windows DLL's would transform their calling conventions dynamically depending on which Pascal compiler had been used by which caller.  Later I read elsewhere that several Pascal compiler vendors for MS-DOS had cooperated in setting some calling conventions so it wasn't that bad.

    "We need an updated and expanded POSIX-like standard for the standard C libraries."

    Didn't the POSIX committee do that?

  • 1. inline keyword

    2. intermingle code and decls

    3. struct initializer

  • "C code is actually crucial, even for large C++ code bases, because as soon as you want to allow interop from different languages or even allow other people to use your software without having to use the same compiler (and switches, etc.), C is a must have."

    This is utter nonsense. Beyond the simple fact that C++ is a widely implemented standard, there is nothing you can do in C that you can't do as efficiently, or more so, in C++. To argue otherwise is to simply stick your fingers in your ears and scream. It's pathetic.

    I still haven't heard a single argument why the C standard should be changed. If a developer is going to change code to take advantage of all the new features, why not just use C++ as a "better C" compiler? (With the added advantage that you can use the object oriented features of C++ as needed.)

  • The above cross-platform sound library has removed support for Windows because the MS C compiler does not handle standard C correctly.

    It should be part of your regression test suite.

  • The above cross-platform sound library has removed support for Windows because the MS C compiler does not handle standard C correctly.

    It should be part of your regression test suite.

  • "Where we’ve received many requests for certain C99 features, we’ve tried to implement them (or analogues)."

    Implementing "analogues" of standardized language features is worse than not implementing the features at all, as it dilutes the value of having the standard, and lends credence to those who say Microsoft abuses its market leverage.  

    Please avoid this practice.

Page 1 of 3 (32 items) 123