C11 for great justice

Last week I blogged a bit about the new 2011 C standard, C11, which is beginning to appear in compilers in the real world.  My basic idea was this

• While GNU uses many languages, C and Guile are the encouraged languages in GNU
• Many new projects avoid C because it is painful
• C11 has features that make it a nicer experience for the applications programmer
• Therefore, GNU should embrace C11

That post got more interest than it deserved, and I've learned quite a lot from the comments here, on HN, and on Twitter.

First, since that post, the GNU Coding Standards have been updated to mention C11.  They now read

1989 Standard C is widespread enough now that it is ok to use its features in programs. There is one exception: do not ever use the“trigraph” feature of Standard C.

The 1999 and 2011 editions of Standard C are not fully supported on all platforms. If you aim to support compilation by compilers other than GCC, you should not require these C features in your programs. It is ok to use these features conditionally when the compiler supports them.

If your program is only meant to compile with GCC, then you can use these features if GCC supports them, when they give substantial benefit.
 

In a policy sense, the modified language isn't much different to the previous version of the standards: basically, use extensions to C89 if they are beneficial, or hold to C89 if you want to be  multi-platform.  Your choice.

Second, with respect to GNOME and C89, Christian Hergert told me this,

 "One of the reasons GNOME (and primarily all the way down to GLib) use C89 is because of the Microsoft C compiler. As sad as that sounds, making sure existing software runs on Windows (things like Gobject, Gtk, Pidgin) is important"

Fine. So when will Microsoft put out a better C compiler? According to Herb Sutter, Microsoft definitely has no plans to update their C compiler: they're just maintaining it without adding new features, so it'll probably remain C89-like forever. A pity, since GCC and Clang have kept moving forward.

However, Microsoft has spent a lot of time trying to bring C++11 to their C++ compiler, and, as a side effect, their C++ compiler has picked up most of the subset of C99 that C++11 contains.  The truth is that if you want to keep native Microsoft compiler support in a free software project, you need to choose one of two strategies

1. Write C89 code forever
2. Write using the intersection of C99 and C++11, and compile using C++ on a native Microsoft build.

Third, I learned that many people really hate VLAs in C.  Odd.  But I was always the type of person that used alloca().  Sure you can error unrecoverably if you overflow the stack, but, avoiding that is simple: just don't allocate anything large enough to overflow the stack.  ;-)

In my tiny slivers of free time, I have kept plugging away at writing a game trying to use the GNOME and GNU libraries.  There's nothing to see, yet.  It is slow going because I was completely unfamiliar with GTK+ and Cairo and Glib and Pulse Audio and the very idea of how to program games. Basically I'm completely out of my paradigm. I've already erased everything and started over twice. But, I think I finally am getting the hang of it.

It is all very different from the work I do in the lab.  But writing the game does have a great advantage: with that project, unlike the code I do at my job, if I screw up it won't result in real human beings dying.  After a career of Mil-Spec and Level B, it is hard to allow myself to just make things work and avoid the perfectionism and paranoia that DO-178B entails.  It is hard to code like I did when I was young, when the joy was in hack and slash and making things work, rather than the craft and drudgery of making things that keep their operators safe from harm.

I wish I could show you some of the code I've done at my real-life job.  It is bananas.

DO178B gets into your head: everything I do in my spare time is either so ridiculously overbuilt that is never gets completed; or it is so rushed and unedited that it can bypass my Freudian super-ego.  The little bit of publicly available free software I've written is in the latter category: it is all crap.  I can't seem to work like a normal person anymore.

C11, yo

I think that the free software community should throw its collective enthusiasm behind the features in the new C language standard -- ISO/IEC 8988:2011.  We should encourage, collectively, that the new features of C11 be used whenever appropriate.

The new C11 standard for the C language has some features I think are exciting.

• Threads and mutexes have been brought into the standard library
• A set of atomics and thread-local storage primitives are defined
• UTF-16 and UTF-32 to multibyte conversion functions are added
• Static compile-time assertions allow the use of sizeof() and friends
• The safer C library functions: fopen_s, strcpy_s, etc.
• Anonymous structs and unions
• Type-generic macros

This is on top of C99 features that haven't been used much

• Variable length arrays, for example

Many of these features have been in gcc for a while; but, the de facto practice has been to avoid extensions for the sake of portability.  There's been a tendency to hold fast to C89 or even pre-K&R C.

For quite a while now, the basic GNU guidance on choosing languages has been to go with C or Guile first, and choose other languages only for special cases.  But the basic GNU and GNOME practice in recent years has been to go with pretty much anything other than C or Guile for new code.  People avoid C because it is too much manual labor, and people avoid Guile for other reasons.

If GNU wants its coders to stick with C in non-kernel space, as a community, we've got to stop discouraging the use of new features that improve the life of a C coder and the readability of C code.

The argument against using new features of C99 and now C11 is that it harms portability.  However, making a virtue of requiring C89 discourages the use of these time-saving constructs, which drives coders away from C, which harms (a different type of) portability.

Variable-length arrays, alone, would save a tremendous amount of time and energy:

int func(int n)
{
  double arr[n];
}

In this case, the array 'arr' is allocated and freed automatically.

All the major C compilers have committed to implementing these features: gcc, clang, and the non-free offerings.  In the next few months, all the major compilers will be up to speed.  Soon the only reason not to use C11 will be because you want to target older or minority compilers.

Let's make our lives just a little bit easier, and use the new features.