Inside checkEndAnalysis(), I cannot find any way to determine the name of the function which was recently analyzed. I wanted to report the results of the analysis inside checkEndAnalysis(). Is there any way to do so? Please help.
You’re looking for
I also very much recommend you to openly discuss your design before putting too much work into it. The
checkEndAnalysis() callback has zero practical applications as of today; it’s used by debug checkers and one dead-end experiment (UnreachableCodeChecker.cpp). Nobody needed it in almost 15 years, so you’re very likely going in a wrong direction.
Thank You for the reply! I was designing a checker to make method declarations const if none of the fields of the class are modified inside the method definition. For that I need to track each and every variable declared inside the method body which references any of the fields. If there are such variables, then I check whether they are modified in the rest of the method body, and if they aren’t modified anywhere, I declare the variable const.
For example, let ‘x’ be a variable referencing a field ‘one’ of some class i.e. int& x = one. If x is not modified later in this scope then I change this line to const int& x = one.
As you might have already understood, to do this I need to maintain a list of such reference variables and track if any of them has been modified. The fact that whether the method itself can be declared const depends on this information. So, I needed a checker which is called once at the end of analysis of a function or a method. I tried checkEndFunction() but it behaves unpredictably in presence of if-else branches(In the sense that it is called before the analysis of every branch of a method body is completed). So, I resorted to checkEndAnalysis(). Please tell if there are any other possible methods.
Ok, this definitely has the same problem as UnreachableCodeChecker: path-sensitive analysis simply doesn’t guarantee that it explores all execution paths. So no matter what analysis reports, you’re never capable of concluding that the method should be const, simply because there may be an execution path on which the member variables are modified, that we’ve missed during analysis. Just like that checker can’t ever conclude that the code is dead.
You should use path-insensitive analysis that can actually reason about all possible paths in finite time, i.e. either purely syntactic analysis or CFG-based data flow analysis.
Yes, I considered purely AST based analysis at the beginning. But, what I require besides actually checking existence of certain constructs or symbols in a method context, is the order of appearance of these constructs. And since path sensitive analysis uses symbolic execution to reason about the ‘paths’ or execution flows in a method body, I thought it to be the better choice.
Also, I think this function “getRootLocationContext()” is deprecated as I cannot seem to find it in ExprEngine.cpp. It’s still mentioned on the documentation page though.