I am looking a tool able to detect ordered function call pairs in a nested fashion as shown below:
f() // depth 0
f() //depth 1
g()
g()
At 开发者_JAVA技巧 each depth of call f()
there must be a call of g()
forming function call pair. This is particularly important in critical section entry and exit.
In C++, one option is to wrap the calls to f()
and g()
in the constructor and destructor of a class and only call those functions by instantiating an instance of that class. For example,
struct FAndGCaller
{
FAndGCaller() { f(); }
~FAndGCaller() { g(); }
};
This can then be used in any scope block like so:
{
FAndGCaller call_f_then_later_g; // calls f()
} // calls g()
Obviously in real code you'd want to name things more appropriately, and often you'll simply want to have the contents of f()
and g()
in the constructor and destructor bodies, rather than in separate functions.
This idiom of Scope Bound Resource Management (SBRM, or more commonly referred to as Resource Acquisition is Initialization, RAII) is quite common.
You may abuse a for
-loop for this.
#define SAVETHEDAY for (bool seen = ((void)f(), true); seen; seen = ((void)g(), false))
The comma operator always lets your functions f
be executed before the dependent statement and g
afterwards. E.g
SAVETHEDAY {
SAVETHEDAY {
}
}
Pros:
- Makes nesting levels clear.
- Works for C++ and C99.
- The pseudo
for
-loop will be optimized away by any decent compiler.
Cons:
- You might have surprises with
break
,return
andcontinue
inside the blocks, sog
might not be called in such a situation. - For C++, this is not safe against a
throw
inside, againg
might not be called - Will be frowned upon by many people since is in some sort extending the language(s).
- Will be frowned upon by many people especially for C++ since generally such macros that hide code are thought to be evil
The problem with continue
can be repaired by doing things a bit more cleverly.
The first two cons can be circumvented in C++ by using a dummy type as for
-variable that just has f
and g
in the constructor and destructor.
Scan through the code (that's the hard part) and every time you see an invocation of f()
, increment a counter. Every time you see an invocation of g()
, decrement the counter. At the end, the counter should be back to zero. If it ever goes negative, that's a problem as well (you had a call to g()
that wasn't preceded by a matching call to f()
).
Scanning the code accurately is the hard part though -- with C and (especially) C++, writing code to understand source code is extremely difficult. Offhand, I don't know of an existing tool for this particular job. You could undoubtedly get clang (for one example) to do it, but while it'll be a lot easier than doing it entirely on your own, it still won't be trivial.
The Coccinelle tool for semantic searching and patching of C code is designed for this sort of task (see also this LWN article on the tool).
精彩评论