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

[Jordan Rose]

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/cc5538d8/attachment.html>