It's a strange thing, but C99 features seem very slow to catch on in the C community, particularly features conceived specifically to alleviate bad "C-isms". The only explanations I can think of are ignorance (not really an excuse after well over a decade) or possibly a subconscious fear that they somehow make a program "less portable", even though basically every compiler supports it (and besides, I've never noticed any aversion to trivial features like //-style comments).
I'm not sure which features you're thinking of. Some are no-brainers: snprintf() is a clear win, and in my experience, it's widely used. I also really like the ability to define structured objects inline using named members, sort of like the way you do in JavaScript. That can make code a lot more readable.
A lot of the rest is just sugar (e.g., C++-style comments). Moreover, many code bases already evolved patterns for dealing with the problems that many C99 features are supposed to address. Booleans are a good example: many environments already have a fine boolean_t definition, and it's not really worth it to convert existing code or introduce a second pattern for representing boolean values.
Variable-length arrays are another good example. They're fine, but alloca() is a perfectly reasonable solution to the same problem, and it's already widely used. IMO, the safety issues usually brought up around alloca() are neither more likely nor more serious than problems like allocating a gigabyte-sized object on the stack or returning a pointer to stack memory. Since competent C programmers don't generally make those mistakes (IME, of course -- I think I've never debugged a problem that turned out to be a misuse of alloca()), I find the added complexity of a new language primitive isn't worth it. (Incidentally, that's the same reason I dislike nearly all of C++.)
> C99 is substantially completely supported as of GCC 4.5 (with -std=c99 -pedantic-errors used), modulo bugs, extended identifiers (supported except for corner cases when -fextended-identifiers is used), and floating-point issues (mainly but not entirely relating to optional C99 features from Annexes F and G).
> The support for standard C in clang is feature-complete except for the C99 floating-point pragmas.
Compiler/library support for C++ is much less complete(standards were published in 1998, 2003 and 2011, and none are completely implemented in any compiler) but that clearly didn't stop people from using C++. The reason is that the commonly supported subset was useful enough. The same is true of C99.
I think it was mostly Microsoft that was holding C99 adoption back by refusing to support it in their compiler suite (officially, they support C++ and C89/C90 only). That means you can't generally compile C99 code with the Microsoft C/C++ compiler, which meant you had to avoid either that compiler or (if you care about portability) the C99 standard. I don't think limited C99 support in GCC or Clang was a limiting factor to anyone in the past decade.
Compiler/library support for C++ is much less complete(standards were published in 1998, 2003 and 2011, and none are completely implemented in any compiler)
Impressive! I see that exported templates got scrapped in the latest standard -- they probably never supported that.
In any case, my point wasn't that Clang was bad (I think Clang is very good) but that the few limitations that might exist in Clang or GCC are probably not holding back C99 adoption.
I'll just note, that after coming back to C after a while in ruby/python/ungh, perl land everything in C99 and C11 has been a welcome change.
Seeing lack of adoption to things like just stdbool.h or even C99 initializer syntax is somewhat amusing. I understand backwards compatibility and all but there seems a general unwillingness to abandon C89 which I can only think is due to the microsoft toolchain.
As to c++ support clang has been really spearheading the implementation of new c++ standards and last I recall they even found bugs or inconsistencies. It always pays to have at least one implementation before standardizing I think.
[EDIT - maybe pride in the bad C-isms?]