Even ignoring personal taste: I care about MSVC. I also care about clang. GCC is the one compiler I'm able to not care about.
> IMHO new C code should be using the gcc cleanup extension
Even if I didn't care about MSVC, I'd disagree.
I'm OK with extensions that are "harmless" in that the program will still run without them working if I #if them out on other compilers - error pragmas, deprecation annotations, static analysis hints, pre-C++11 override keywords, etc.
I'm not OK with self inflicting vendor lock-in for something as important as cleanup rely on a specific compiler's extensions - especially not when we have a perfectly standard, portable, significantly better tested (and thus less likely to have bugs) reasonable alternative in the form of C++ destructors.
If I'm not using C++ destructors, it's either because:
1) I'm doing small changes to an existing C project (in which case I'd be stylistically inconsistent with it's preferred cleanup patterns for minimal gain, since it almost certainly doesn't use the gcc cleanup extension)
or
2) because I can't rely on having decent C++ compilers on my target platforms (which means I can't rely on having GCC either, and thus can't rely on the gcc cleanup extension by definition.)
> For what its worth, it is only MSVC without support.
How recently? I've been enough versions back that clang documented pragmas haven't been available. The cleanup attribute... I can only find docs for GCC. Although I see LLVM bugs for it, so you're right about clang supporting it - at least on HEAD.
> gcc compiler extensions are otherwise still rather portable.
Portable or not, I'd say only about half the extensions I've sought out on clang have actually been available. If that.
> To clang and icc at least.
I should note in scenario #2 above I don't have these available either, since these are decent C++ compilers.
If you don't care about MSVC, IMHO new C code should be using the gcc cleanup extension: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initial...