[cfe-dev] Static Analyzer - tracking values through indirection?

[Gábor Kozár]

By function and method inlining, you mean, inter-procedural analysis
support via inlining the called methods? That seems like an interesting
choice. We were just discussing this today, that is, how to efficiently
support inter-procedural analysis, and this was one idea that came up. Good
to know that we had a right idea then. :)

Thanks for the info!


2013/5/2 Jordan Rose <jordan_rose at apple.com>

> Ah, yes. Function and method inlining should already be enabled in 3.2,
> but constructor (and destructor) inlining was not. Hopefully 3.3 will make
> your life a bit easier!
>
> Jordan
>
>
> On May 2, 2013, at 11:40 , Gábor Kozár <kozargabor at gmail.com> wrote:
>
> Hi Jordan,
>
> They are in the same TU, in fact, inside the very same file. I'll be able
> to give you further details (e.g. the dump()-ed SVals) on Monday.
>
> Can it be that support for same-TU inter-procedural analysis was added
> after 3.2? We're using clang 3.2 to avoid stability and
> backward-compatibility issues.
>
> Thanks!
>
>  Gabor
>
>
> 2013/5/2 Jordan Rose <jordan_rose at apple.com>
>
>> I think you mean cross-translation-unit analysis. IPA within one
>> translation unit has been supported for a while. Just to be sure, does your
>> example work if you put definitions of DummyTransaction's methods in the
>> same translation unit?
>>
>> Jordan
>>
>>
>> On May 2, 2013, at 8:16 , Gábor Kozár <kozargabor at gmail.com> wrote:
>>
>> Hi,
>>
>> Never mind this e-mail, I realized that tracking this would involve
>> inter-procedural analysis, which the Static Analyzer currently does not
>> support.
>>
>> Sorry for the spam!
>>
>> Gabor
>>
>>
>> 2013/4/30 Gábor Kozár <kozargabor at gmail.com>
>>
>>> Hi,
>>>
>>> I need to write a checker to make sure that the state of the transaction
>>> is checked after commit. This is working fine is basic cases, but it seems
>>> to fail when I introduce any level of indirection. For example, consider
>>> the following:
>>>
>>> class TransactionPtr
>>> {
>>> public:
>>>     TransactionPtr(DummyTransaction& tr) : m_tr(tr) {}
>>>
>>>     DummyTransaction* getTransaction() { return &m_tr; }
>>>
>>> private:
>>>     DummyTransaction& m_tr;
>>> };
>>>
>>> int main(int argc, char* argv[])
>>> {
>>>     DummyTransaction tr;
>>>     TransactionPtr trp(tr);
>>>
>>>     trp.getTransaction()->commit();
>>>
>>>     if(tr.isSuccessful()) return 0;
>>>     else return 1;
>>> }
>>>
>>> Running my checker on this reveals that the analyzer has no idea of the
>>> connection between trp.m_tr and tr, and so it fails to detect an issue with
>>> the above code.
>>>
>>> I also tried checkBind(), but it is not called in relation to the
>>> TransactionPtr trp(tr); line.
>>>
>>> Is this a known limitation, or am I missing something here? I also tried
>>> getBaseRegion(), getSuperRegion(), which didn't lead anywhere.
>>> getMemorySpace() on the other hand points to UnknownSpaceRegion.
>>>
>>> Thanks!
>>>
>>> Gabor
>>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130502/759f5734/attachment.html>