[cfe-dev] Analyzer: Extract region-walking behavior from CallAndMessageChecker

[Ted Kremenek]

I understand your point, but I think I still strongly disagree here.

I'm fine with the checker behavior being controlled by an option, but just having the code go in as is (with these obvious algorithmic performance issues) sets a bad precedent for how we think things should "get done" in the analyzer.  The current check should probably be changed as well because of this reason.

Implementing this the right way involves extending StoreManager with the right APIs so that the query can get executed efficiently.  We shouldn't just hack things into the analyzer because it is immediately convenient, especially when doing it right isn't necessarily that hard.  Having good design and thinking these issues out at the appropriate times is well worth it in the long run, as hacks have a way of piling up.

On Jun 26, 2010, at 10:33 PM, Zhongxing Xu wrote:

> With a command line option, the user could decide to turn it on if he
> can tolerate the cost and knows his code should not have uninitialized
> fields.
> 
> On Sun, Jun 27, 2010 at 1:23 PM, Ted Kremenek <kremenek at apple.com> wrote:
>> To clarify, I think I was trying to make two points.  The first was that the direct walking was likely to be prohibitively expensive.  The second was that the check was likely to yield many false positives.  For the first point, we can possibly deal with the efficiency problem by rephrasing the task as some kind of query on the StoreManager that we specifically have the StoreManager implement in some efficient way.
>> 
>> On Jun 26, 2010, at 9:19 PM, Zhongxing Xu wrote:
>> 
>>> Hi,
>>> 
>>> I agree with Ted that such explicit walking each element could be
>>> expensive. But if such check shows some value, we can conditionally
>>> turn it on with a command line option like
>>> '-analyzer-check-uninit-fields' and let the user decide.
>> 
>>