The question is whether this can be done relatively cleanly and portably.
The answer is that it cannot.
Aside from all the non-portable details of how the call stack is implemented on different systems, suppose foo gets inlined into bar. Then (generally) it won't have its own stack frame. You can't cleanly or portably talk about reverse-engineering a "double" or "n-times" return because the actual call stack doesn't necessarily look like what you'd expect based on the calls made by the C or C++ abstract machine.
The information you need to hack this is probably (no guarantees) available with debug info. If a debugger is going to present the "logical" call stack to its user, including inlined calls, then there must be sufficient information available to locate the "two levels up" caller. Then you need to imitate the platform-specific function exit code to avoid breaking anything. That requires restoring anything that the intermediate function would normally restore, which might not be easy to figure out even with debug info, because the code to do it is in bar somewhere. But I suspect that since the debugger can show the state of that calling function, then at least in principle the debug info probably contains enough information to restore it. Then get back to that original caller's location (which might be achieved with an explicit jump, or by manipulating wherever it is your platform keeps its return address and doing a normal return). All of this is very dirty and very non-portable, hence my "no" answer.
I assume you already know that you could portably use exceptions or setjmp / longjmp. Either bar or the caller of bar (or both) would need to co-operate with that, and agree with foo how the "return value" is stored. So I assume that's not what you want. But if modifying the caller of bar is acceptable, you could do something like this. It's not pretty, but it just about works (in C++11, using exceptions). I'll leave it do you to figure out how do do it in C using setjmp / longjmp and with a fixed function signature instead of a template:
template <typename T, typename FUNC, typename ...ARGS>
T callstub(FUNC f, ARGS ...args) {
try {
return f(args...);
}
catch (EarlyReturnException<T> &e) {
return e.value;
}
}
void foo(int x) {
// to return early
throw EarlyReturnException<int>(1);
// to return normally through `bar`
return;
}
// bar is unchanged
int bar(int x) {
foo(x);
/* long computation here */
return 0;
}
// caller of `bar` does this
int a = callstub<int>(bar, 0);
Finally, not a "bad-practice lecture" but a practical warning -- using any trick to return early does not in general go well with code written in C or written in C++ that doesn't expect an exception to leave foo. The reason is that bar might have allocated some resource, or put some structure into a state that violates its invariants before calling foo, with the intention of freeing that resource or restoring the invariant in the code following the call. So for general functions bar, if you skip code in bar then you might cause a memory leak or an invalid data state. The only way to avoid this in general, regardless of what is in bar, is to allow the rest of bar to run. Of course if bar is written in C++ with the expectation that foo might throw, then it will have used RAII for the cleanup code and it will run when you throw. longjmping over adestructor has undefined behavior, though, so you have to decide before you start whether you're dealing with C++ or with C.
baras well or doing some stupid tricks with exceptions. This kind of thing is entirely what the structured programming movement was fighting against (reasonably and successfully, i should add). – Nympho