开发者

How to detect correct function call pairs

开发者 https://www.devze.com 2023-01-11 06:33 出处:网络
I am looking a tool able to detect ordered function call pairs in a nested fashion as shown below: f()// depth 0

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 and continue inside the blocks, so g might not be called in such a situation.
  • For C++, this is not safe against a throw inside, again g 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).

0

精彩评论

暂无评论...
验证码 换一张
取 消