Slightly more than a year ago we started to use gcc's "cleanup" C attribute extensively in the +systemd
sources. Today, from this experience I can only tell you what a fantastic feature this is. It is probably the greatest extension to the C language of the last 10 years, and it substantially improves the readability of your code and the quality of error code paths.
Usually in most non-trivial C programs the error code paths are a real weakness. They are seldom tested, and it is easy to forget to destruct everything correctly and in order. Error cleanup handling adds substantial amounts of code, and make sources harder to read since the essence of the logic is hidden between glue code you need for error handling. With the gcc cleanup attribute most of this is a thing of the past: you define how to destruct some object when you declare its variable, and gcc will do the rest for you, regardless how and when you exit the function or code block. Your code is hence reduced to the essentials, it will express only what you want to express and you will not get lost in error processing. You can just do a "return -EINVAL" wherever you like, and gcc will clean up things as necessary. With the gcc cleanup attribute C almost starts feeling like a high-level language, and not just like the fancy assembler language it actually is...
Of course, using this functionality comes at a price: while any recent gcc versions support it just fine (actually even older ones do), and intel and llvm do too, you do lose out on retro C compilers like Microsoft's. But for everybody who doesn't care about that: try it out, use it, it's absolutely liberating, and breathes new life into the C language.
we use it widely in internal code, though for public shared library APIs we try to be conservative (actually, very conservative: C89). However, I am thinking of actually exposing high-level macros making usage of the cleanup attribute easy for systemd's own API objects. Since people who care for C89 compat can opt to simply not make use of the macros this should be an OK thing to do.
I am pretty sure that large projects (like even the Linux kernel...) could easily delete 10% or 20% of their code, if they just started making use of this concept. And it would improve code quality, too. Libraries such as glib really should encourage using this concept, by providing nice support for it via friendly macros. It makes programs better and smaller, and developers happy.
Oh, and credit where credit is due, Upstart's libnih has been one of the early users of it, and we got inspired to use it from there.
And now, enough of this friday evening rambling, have a look at the gcc documentation describing it.