Clang Static Analyzer finds 7 problems in 2.2

[Monte Ohrt]

FYI, the Clang static analyzer finds 7 problems with RegexKitLite 2.2. I'm not sure of the severity, but it might be worth a look. Here is a summary:

Call to function 'CFStringCreateWithSubstring' returns a Core Foundation object with a +1 retain count (owning reference)
Object allocated on line 962 is no longer referenced after this point and has a retain count of +1 (object leaked)

Object allocated on line 696 is no longer referenced after this point and has a retain count of +1 (object leaked)

Object allocated on line 639 is no longer referenced after this point and has a retain count of +1 (object leaked)

543 dereference null pointer

616 Value stored to 'stackUsed' is never read

684 Value stored to 'stackSize' is never read

[Monte Ohrt]

Forgot one:

Object allocated on line 695 is no longer referenced after this point and has a retain count of +1 (object leaked)

[John Engelhart]

I appreciate the heads up.

I've used clang to check RegexKitLite for most of the releases that have gone out the door.  I filed a bug (http://llvm.org/bugs/show_bug.cgi?id=2580) regarding the false positive memory leaks, but it's one of those 'understandable' false positives when you dig in to it.  It has to do with the fact that RegexKitLite supports all three memory management paradigms: manual retain/release, full Garbage Collection only, or dynamic 'mixed-mode' that picks the right one on demand at program load time.  That flexibility causes the (auto)releases to the objects to be 'obscured' from clang because clang currently doesn't perform inter-procedural analysis (ie, it doesn't follow the program execution flow through function calls, it can only analyze the current function it is examining).

The null dereference is also another false positive that would be silenced once clang is IPA capable.  It's pretty simple to manually walk through the inter-procedure control flow and verify that the dereference it is complaining about will always contain a valid, non-NULL value.

The dead-stores are legitimate, but harmless.  I left them there because the optimizer will easily clean it up, but more importantly I don't have to remember to 'add it back in' at some point if I ever add something past that point that requires an accurate count of the number of bytes used off the stack.  :)

If you're feeling particularly adventurous, you can grab a sort of "3.0 preview" at http://llvm.org/bugs/show_bug.cgi?id=3949 by grabbing the attachment for that bug report.  I think it goes without saying that that version probably isn't "production worthy" :)