<div dir="ltr"><div class="gmail_extra">Hi Jordan,<br><br>Thanks for the reply, a lot of useful information!<br></div><div class="gmail_extra"><br><div class="gmail_quote">2013/7/26 Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Compiler-generated destructors aren't ignored, but trivial destructors are. This is intentional, since it simplifies the CFG and general analysis and makes the analyzer do less work, but we wouldn't have to keep it that way. Still, if the destructor is trivial, what cleanup is it supposed to be doing? (I guess if it's trivial when it's <i>supposed</i> to be doing cleanup it'd be a problem. An AST-traversal check might be the way to go for that, though, rather than spending the full efforts of a path-sensitive engine to tell you you didn't implement something.)</div>

<div></div></blockquote></div><br></div><div class="gmail_extra">This is a significant issue, as it makes it impossible for me to efficiently clean up resources used for tracking objects. checkDeadSymbols only tells me about very-very few deaths, and I haven't yet seen it tell me that a region has died. Many objects have trivial dtors. For example, I'm now writing a checker that aims to detect invalidated iterator usages. Obviously, when an iterator object dies, I can stop tracking it. Granted, the tracking information is not too significant in this case (2 bools), but you see the problem.<br>

<br>--<br><br></div><div class="gmail_extra">Anyhow, a different question: we have a number of custom-built checkers now, and some of which are pretty general, and probably would be useful as a built-in checker as well. I'm far from satisfied with them at this point, but once I am (hopefully by September), we could consider contributing these to the Clang repository (my boss hasn't yet agreed, but I'll be pushing the question). What is the procedure for this?<br>

<br>--<br><br></div><div class="gmail_extra">In my current checker, I need to detect whenever a particular value is used. For instance, when it appears in a function argument, or it is assigned to, etc. checkLocation will only fire for Loc-type Svals, which makes sense, except it's not useful here.<br>

</div><div class="gmail_extra">For now my only idea is to use checkPreStmt, and search the stmt for such references... except that is terribly inefficient. I guess for now I will just look for DeclRefExpr-s and MemberExpr-s, try to obtain their SVal, then get the symbol/memregion from the SVal, then check if I have any info associated with it in the programstate (i.e. whether it is tracked)...<br>

</div><div class="gmail_extra">Is the lack of such interface in Clang SA deliberate? I could imagine like a checkVariable(SVal val, const Expr* refExpr, const Stmt* environment, CheckerContext& context). I can imagine this would very inefficient, so it would probably need to be paired with some opt-in mechanics, like the checker has to say "I want to be notified whenever this variable is used" - maybe similarly to how checkRegionChanges are.<br>

</div><div class="gmail_extra">Any thoughts on this?<br><br></div><div class="gmail_extra">Again, thank you all (Ted, Anna, Jordan, and anyone else I forgot to mention) very much for all this support you're giving here, it is most appreciated!<br>

<br>Gabor<br></div></div>