One comment about the dead stores: even if it doesn’t identify real bugs for you, it should never flag a store as being dead if that value is ever read. Put another way, if the check flags a dead store, it really should be a dead store. That particular check is not suppose to emit any false positives. If you notice such cases, please feel free to file a bug report.

Thanks for your continuing feedback regarding the tool!

We did start working through some of our dead stores, and did find at least one bug in them. But most of them have yet to be useful. The new flags to turn these reports on/off in the newer builds are cool and should settle that though. Thanks!

For the MissingDealloc check, yesterday (after reading your comments) I added support in the analyzer to not flag warnings for objects whose ivars are all IBOutlets (please report problems when this doesn’t work). This should now be in checker-62 or later (available at http://clang.llvm.org). If anyone has ideas of how the MissingDealloc check can be further improved, please feel free to file a Bugzilla report via the Clang website.

As for the dead stores checker, its purpose is to identify logical mistakes, not penalize legitimate code, so I am completely open to making it smarter to work with different coding idioms. This checker has actually found interesting bugs in code at Apple, with sometimes the check identifying performance bugs and other cases identifying insidious logic errors. From the performance side, although the optimizer in a compiler can optimize away the store itself, it cannot always optimize away the computation used to generate the value that would be stored to the variable. This is particularly the case when the value is computed via Objective-C message expressions; since Objective-C is so dynamic, the compiler takes a conservative approach and typically cannot ever inline the called methods. This means that dead method calls will always be executed, so dead stores can be useful in identifying optimization opportunities for the programmer.

To help address some of your own concerns, in checker-62 I also added support in the analyzer to distinguish between “dead initializations” and “dead stores”, which may go part of the way to give you a way to automatically filter some of the false positives for your specific coding idiom. I realize that this may not actually help you for your use of error variables, but in general it should be helpful for users to better triage these bugs. Any suggestions of how to further refine the reporting of dead store bugs to make this check more useful are welcome!

As for reporting more information such as BUGDESC, BUGLINE, etc., we can easily report more information. Please feel free to file Bugzilla reports with such feature requests! We want to make the workflow of using this tool both flexible and fluid, so suggestions of how the workflow can be improved are greatly appreciated. There has also been some mention on the Clang developers’ mailing list to potentially support XML output from the analyzer. This would help enable others who wanted to build their own report tracking and presentation infrastructure. This is something that I personally won’t have time to work on in the near future, but since the entire tool is open source, anyone who is interested in helping is welcome to do so (more information on the Clang website).

When I write new code, I generally enable as many checks and diagnostics as possible on the assumption that it will improve the quality of the code, and make it more maintainable and readable. I find the aforementioned method a good way of saying “yes, I know this is unused” in e.g. main(). Wrapping it in a macro and optionally using __attribute__((unused)) might be even better.

(I’m a measly CS student, so I wouldn’t know whether it actually works out there in the Real World ;))

Why? Because by assigning it to a variable, you can see the error code in debug builds, or potentially even attach conditional break points.

Most of the MissingDealloc false positives are coming from Window/View objects whos ivars are all IBOutlets (and thus released by NSWindowController or the like). Over time we’ll probably just add -deallocs to all our classes, as stylistically I think that is a beneficial thing to do.

The DeadStores on the other hand, bug me more. We often do DeadStores on purpose, like: int err = doStuff(); //Ignore error because we don’t care if doStuff() fails. This way the code annotates that an error is returned, and ignored on purpose. These I have no plans on changing.

I believe the true solution for false positives though, is a way of tracking these bugs, this way a false positive can be marked as such, and ignored from future reports. Between BUGDESC, BUGLINE and BUGPATH we can almost do this now, but not quite. If we had just a little more information like the function the bug is in, and the line number relative to the start of the function (or similar), that would be enough for us to build a persistent tracker on top of the reports.