I am not excited about any of the new features ( except many aligned_malloc) and I write C for a living. I think you get to a point with a language with C where I actually _dont_ want much change everything works just the way it is and we have dealt with its warts for decades. I am actually a little leery of the thread additions and the atomic additions. I feel that shouldn't be a part of the language specification and I would much rather see that incorporated at a higher level.
Presumably you are familiar with Boehm's famous "Threads Cannot be Implemented as a Library" [1]. Meanwhile, pthreads require heavyweight OS involvement and implementing a simple spinlock requires inline assembly or non-portable compiler builtins. There is still no widely-used portable library of atomics (the Linux kernel is the most complete I know of, but their atomic support isn't trivial to extract for use outside the kernel, and it was only written for one compiler (gcc)). I'm definitely looking forward to stdatomic.h. Unfortunately, compilers are already mis-applying [2] the macros that are supposed to be available for determining the presence of thread and atomic support, so, as usual, configure tests are needed for everything.
That's an interesting project, but it doesn't qualify as portable yet since it's currently entirely dependent on gcc inline assembly syntax and doesn't support a number of important architectures, including ARM. Thanks for sharing though, I'll keep an eye on it.
It is _portable_. It's not intensively _ported_ yet:
Archs: Power, SPARCv9, x86, x86-64
Compilers: gcc, clang, icc, suncc
Adding a wildly different compiler shouldn't be the end of the world but it would need some build sys work and a new compiler wrapper.
Samy was focusing on a few archs that help debug the code. I got him access to the GCC build farm, but the ARM boxes there were fairly weak when I remember. Access to good hardware might help him move it along.
For those of us who do numerical programing, the new complex initializer macros are a huge improvement; previously it was quite painful to initialize complex values with an infinite imaginary part without resorting to non-portable extensions.
It's a minor fix, but it's vastly better than what was there previously, and it's exactly the sort of change that works really well in C; incremental fixes that are carefully thought out and easy for both implementors and users to adopt.
I am actually a little leery of the thread additions and the atomic additions. I feel that shouldn't be a part of the language specification and I would much rather see that incorporated at a higher level.
What higher level? POSIX? Personally, I believe things like atomicity and alignment do belong into the language specification.
Also keep in mind that the multithreading support as specified by C11 is closely aligned with C++11.
