C99 adds several useful features to the language, yet I find it difficult to recommend any practice which depends upon C99. The reason for this is because there are few (any?) a
FreeBSD is now using Clang for kernel compiles and that pretty much supports C99.
You should use C99 whenever you are not locked in an environment that doesn't support C99 (embeded systems most notably).
And yes, if you know that your library will be used by people that are using MSVC, you can't use C99 features in the interfaces, but there is no reason not to use C99 in the implementation (apart from library feature dependencies of course).
Original answer: "Uh? What compilers don't support C99? Plus when you move from compilers to tools, C99 is actually more commonly supported then C89."
MSVC does not, nor will it probably ever, support C99. But Microsoft has little incentive to update their C compiler. It's not like they will lose much business over it.
But there are plenty of compilers that have support for C99.
http://en.wikipedia.org/wiki/C99#Implementations
Regarding gcc:
http://gcc.gnu.org/c99status.html
You are right that perhaps C99 is not useful for library code (and may never be without Microsoft's support), but if you're working on an in-house or personal project where you can pick the compilers and tools, then the portability is not much of an issue.
If you care for performance, there's no way around restrict
.
C99 brings features that really makes programming in C easier and more error safe:
for
-scope variablesThe language is also much more expressive with
inline
functionsOn my linux machine I have four compilers that support C99 to a satisfying extent that make this usable on a daily base: gcc, clang, opencc and icc.
The first two are open source compilers where clang trying to be code compatible to gcc (meaning C99 support is about the same).
The later two are from the two major CPU producers and are commercial but with generous license policy for non commercial users. Their C99 is a bit less, in particular their support for inline
seems not completely consistent with the standard, yet.
Regarding C1x, I think it's worth noting that the standards committee is well aware that C99 has not been widely adopted and doesn't want to repeat the same mistakes (or to make the situation worse). From the C1x charter:
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.
And:
The original standard had a very positive reception from both the user and vendor communities. However, C99 has been not so widely received.