CFRefCount Problem #1: Receiver Aliasing

Jordy Rose wrote:

[Background: Currently we're trying to eliminate the concept of "transfer functions" from the static analyzer, which has gradually been supplanted by the Checker interface. The only implementation of the transfer functions, CFRefCount, has two roles: general-purpose function and method evaluator, and retain-count checking for the Cocoa and CoreFoundation frameworks. The former is being moved to ExprEngine*, the latter to a regular checker called RetainReleaseChecker.

I hope this does not mean downgrading the static analyzer.
It's extremely useful to find retain/release bugs simply by adding --analyze.

Robert P.

No, no. We just want to make it so that the retain/release structure isn't tied in to the core of the analyzer. Right now the analyzer doesn't work at all without the retain/release checks, but there's no reason why it /has/ to be that way anymore. It'd be nice if the retain/release checking could be turned on and off like any other check -- pure C++ code, for example, shouldn't need to do this extra work.

I'm pretty sure RetainReleaseChecker will still be enabled by default, at least on Mac OS X.

Jordy

Indeed. This checker isn’t going away in any shape or form. We’re just refactoring the implementation.

Thanks for your replies.
I am confused between --analyze and scan-build. Both claim to be The Static Analyzer but they differ non-trivially in packaging, ease of use, fit to our workflow, and presentation of marvellously OTT annotated source. Do they, at least in principal, find the same set of issues?

What I meant to ask was whether much-prized functionality was being removed from --analyze.

Robert P.

I hope this does not mean downgrading the static analyzer.

It’s extremely useful to find retain/release bugs simply by adding --analyze.

No, no.

I’m pretty sure RetainReleaseChecker will still be enabled by default, at least on Mac OS X.

Indeed. This checker isn’t going away in any shape or form. We’re just refactoring the implementation.

Thanks for your replies.
I am confused between --analyze and scan-build. Both claim to be The Static Analyzer but they differ non-trivially in packaging, ease of use, fit to our workflow, and presentation of marvellously OTT annotated source. Do they, at least in principal, find the same set of issues?

They do find the same set of issues.
scan-build is a script which interposes on the project build process to call the analyzer (for more, see http://clang-analyzer.llvm.org/scan-build.html). For example, it allows one to run the analyzer on projects with existing build systems.
–analyze is the clang compiler option to call the analyzer.

The analyzer supports different forms of output like html, text. For example, to choose html:
$ clang --analyze example.c -v -Xanalyzer -analyzer-output=html -o outdir

Anna.

Hi Robert,

scan-build is meant to be a shrink-wrapped, mostly stable way of analyzing a project. --analyze was a hook added to originally allow Xcode to drive the static analyzer from the IDE, but other’s have taken to using it. It is really a non-stable interface that has never been publicly documented, and I discourage it’s direct usage unless you really know what you are doing. The reason it is discouraged is because over time we will be evolving how the analyzer handles multiple files. Currently the analyzer analyses each file separately, but we’d like to move to a place where it can analyze multiple files together and pool the information garnered from doing so. The --analyze model inherently sits in the “analyze each file separately” workflow, whereas using scan-build marginalizes out such details.

Cheers,
Ted

I wrote:

I am confused between --analyze and scan-build. Both claim to be The Static Analyzer but they differ non-trivially in packaging, ease of use, fit to our workflow, and presentation of marvellously OTT annotated source. Do they, at least in principal, find the same set of issues?

Anna Zaks wrote:
They do find the same set of issues.

Ted Kremenek wrote:

scan-build is meant to be a shrink-wrapped, mostly stable way of analyzing a project. --analyze was a hook added to originally allow Xcode to drive the static analyzer from the IDE, but other's have taken to using it. It is really a non-stable interface that has never been publicly documented,

Except for this somewhat public mention.
$ clang --help
OVERVIEW: clang "gcc-compatible" driver

USAGE: clang [options] <inputs>

OPTIONS:
  -### Print the commands to run for this compilation
  --analyze Run the static analyzer
[...]

and I discourage it's direct usage unless you really know what you are doing. The reason it is discouraged is because over time we will be evolving how the analyzer handles multiple files. Currently the analyzer analyses each file separately, but we'd like to move to a place where it can analyze multiple files together and pool the information garnered from doing so. The --analyze model inherently sits in the "analyze each file separately" workflow, whereas using scan-build marginalizes out such details.

I believe I understand now, thanks. The two forms of static analysis currently find the same set of issues, but will diverge in the future, for good reason.

My apologies for high-jacking this thread. Should have started a new one "Will the Real Static Analyzer please stand up?".
Robert P.