False positives are something we're very concerned about, and we planning on addressing them in several ways. The memory leak checker you refer to doesn't do inter-procedural analysis right now, and infers the effects of functions (e.g., CFRelease) from the strict naming conventions for these functions (as well as their type signatures). Once inter-procedural analysis is in place, the analyzer should be able to automatically handle wrappers to CFRelease and friends.

Inter-procedural analysis only is a partial solution, since the implementations of these functions might not be available to the static analysis tool (e.g., if they are buried in a library whose source is unavailable). A complementary solution is to provide attributes that can be affixed to the function prototypes of wrapper functions (which are declared in headers) that the checker can leverage to understand the a function has a certain functionality and thus reduce false positives. This solution is nice because it makes the checking more modular, and documents the interface of the function without requiring full-blown inter-procedural analysis. The syntax of these attributes would be similar to GCC attributes, but could easily be sugared with the use of preprocessor macros:

http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes

Would attribute support like this be useful? Conceptually, we would add a few checker-specific attributes to Clang, and provide a header file that #defined a set of macros that expanded to these attributes when using Clang and would expand to nothing when not using Clang. That way GCC eats your code with no problems.

If this sounds like a good feature, feel free to shoot me an email directly, or send an email to the Clang developers' mailing list: