[cfe-dev] NSAutoreleasePool checker

[Ted Kremenek]

On May 27, 2011, at 7:22 AM, David Chisnall wrote:

> Hi Ted,
> 
> The problem is that the GC setting is dependent on the current compilation mode, not on the deployment target.  If you are writing a framework that may be compiled in GC or non-GC mode, then you may well be building it and running the analyser in non-GC mode (e.g. for targeting the iPhone), but it would be helpful for the analyser to warn you that you're using the autorelease pool in a non-recommended way.  Someone who grabs your framework for use on another platform may compile it with -fobjc-gc, but not run the analyser, so no one will ever see the message.  

Hi David,

In my opinion, the analysis results should depend on the current compilation mode.  We have a variety of checkers that take into account the current target triple (and other settings) when making decisions.

For example, consider the ObjC memory management checker.  Currently it does a dual analysis if one passes -fobjc-gc: one for manual reference counting, the other for GC.  Whether or not the code runs in GC strongly impacts the kind of analysis results we get from that checker.  For those users not using GC, they would be extremely annoyed if we reported GC-specific bugs (or vis versa) for a mode that there code never runs in.   Also consider the impact on the target architecture on the sizes of primitive types; these can impact static analysis results in subtle ways, and also cause some checkers to fire in some cases but not others (e.g., 64 versus 32 bit).

> I've just fixed 74 instances of this in the GNUstep code.  Most of the people working on the project are building in non-GC mode, so if they run the analyser, they won't see this warning, but it is something that should be fixed for people who do then build the code with GC enabled.

Honestly, a framework developer who cares about deploying in multiple settings should be running the analyzer for each of those cases.  The argument is really no different than for testing a framework (one should be testing for each of the deployment settings).  While this ostensibly looks like a case where we can just check all the time, I just don't think (a) this would have value for people who don't care about GC and (b) really sidesteps the general picture that some checks will inherently have different behavior depending on the compilation target and mode.

In the case of GNUstep, if the majority of the developers aren't compiling for GC, then this sounds like something that could be addressed by integration testing.  For example, a buildbot could be running the analyzer in GC mode, and reporting new results.  As callous as that sounds, I don't think this is unreasonable.  For the LLVM project, it is not possible for developers to test on every host platform (e.g, Linux, Mac, FreeBSD, etc) that we care about.  For GNUStep, deployment to different memory models sounds like a worthy thing to test with automatic testing, both with and without static analysis.

Of course, you are free to make whatever changes you want to Clang for your own setup (which I imagine you have), but I don't think this is the right decision for mainline Clang.

Cheers,
Ted