Why -checker-simple is disabled in scan-build?

Hi,

Why not list -checker-simple in the available analyses in scan-build?

  • Zhongxing Xu

No real reason, other than -checker-cfref functionally does the same thing as -checker-simple except that it does the retain/release checking for Objective-C. All -checker-simple does is run the path-sensitive engine and execute its internal checks. It's also a bad name. "-checker-basic-checks" instead?

No real reason, other than -checker-cfref functionally does the same thing as -checker-simple except that it does the retain/release checking for Objective-C. All -checker-simple does is run the path-sensitive engine and execute its internal checks. It’s also a bad name. “-checker-basic-checks” instead?

I prefer shorter name “-checker-basic”. What do you think that we make it available for pure C code checking?

-checker-basic sounds fine.

Just to be clear, -checker-cfref works on C code as well. It just knows about the retain/release methods and also tracks reference counts. It does all the same checks as -checker-simple does, and the performance impact is so minimal it didn't seem worth confusing people with two options and always run with "maximum checking." That said, we probably should provide a separate scan-build option to run -checker-basic, and maybe one option, -checker-all-checks, that enables everything.

The current transfer function implementation is not designed will for checker composition, and I see this as the next big overhauling in the design of the system. Right now the code in CFRefCount.cpp does some redundant work also done in GRSimpleVals.cpp, and the transfer function object defined in CFRefCount.cpp also subclasses GRSimpleVals.cpp and overrides some of its virtual functions. This just doesn't seem very modular to me. To me, a "checker" should be act like a plug-in transducer that can be interposed at different places and change the state while also coexisting with other checkers that can also change the state. I'm not certain what is the best way to do this. The Generic Data Map (GDM) model in GRState was added to help facilitate this, so that there was a common data representation in GRState for different checks to work with and plug in arbitrary checker-specific data.

As more checks get added, there will be more checks analogous to -checker-cfref: -checker-malloc, -checker-my-special-api, etc. To me all these should do is enable extra checks.

Exactly. Right now there is not many different transfer functions other than GRSimpleVals due to the BasicStore limitation. So how to modularize transfer functions seems still unclear. But when we have RegionStore in position, the necessity is obvious. Foremost, state splitting will be common. For example, when we have to assign to an array element with a symbolic index, assume the symbolic index to be every or random possible value and split up the state is necessary.