Dead stores of NULLs

First I would like to express my appreciation for the great static analyzer, which is already producing useful results. I've been able to find several memory leaks and some dead stores. However, I would like to address an issue which produces some dead store reports which are technically correct (they really are dead stores), but I would still like to ignore them.

When I allocate an object (by using alloc & init* or one of the *Create* functions) and store it into a local variable inside some scope, I tend to set it to nil/NULL after the object has been released. This is an intentional dead store, which prevents any use of that released object later in the same scope. For example:

- (void)doSomethingWithFileExtension:(NSString *)ext
{
  CFStringRef fileUti = UTTypeCreatePreferredIdentifierForTag(kUTTagClassFilenameExtension, (CFStringRef)ext, NULL);

  // use 'fileUti'...

  CFRelease(fileUti);
  fileUti = NULL; // Dead store, reported correctly by 'scan-build'

  // From now on, any unintentional use of 'fileUti' variable in this method will cause predictable runtime behaviour.
  // If it'll be passed to some other methods, precondition assertions of those methods will catch it early etc.
}

Would it be useful to add a flag to ignore nil/NULL dead stores?

- Nikita

First I would like to express my appreciation for the great static
analyzer, which is already producing useful results. I’ve been able to
find several memory leaks and some dead stores.

That’s wonderful to hear!

However, I would like
to address an issue which produces some dead store reports which are
technically correct (they really are dead stores), but I would still
like to ignore them.

When I allocate an object (by using alloc & init* or one of the
Create functions) and store it into a local variable inside some
scope, I tend to set it to nil/NULL after the object has been
released. This is an intentional dead store, which prevents any use of
that released object later in the same scope.

I agree, the dead store checker is meant to find bugs, not penalize defensive programming. The following patch causes dead assignments of null to pointers to not be treated as warnings:

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080616/006188.html

checker-42 (on the clang website) includes this patch. If you find cases where this fix doesn’t handle all cases, please let me know.

Ted