I would like to be able to force a 'double-return', i.e. to have a function which forces a return from its calling function (yes, I know there isn't always a real calling function etc.) Obviously I expect to be able to do this by manipulating the stack, and I assume it's possible at least in some non-portable machine-language way. The question is whether this can be done relatively cleanly and portably.
To give a concrete piece of code to fill in, I want to write the function
void foo(int x) {
/* magic */
}
so that the following function
int bar(int x) {
foo(x);
/* long computation here */
return 0;
}
returns, say, 1; and the long computation is not performed. Assume that foo() can assume it is only ever called by a function with bar's signature, i.e. an int(int) (and thus specifically knows what its caller return type is).
Notes:
- Please do not lecture me about how this is bad practice, I'm asking out of curiosity.
- The calling function (in the example,
bar()) must not be modified. It will not be aware of what the called function is up to. (Again in the example, only the/* magic */bit can be modified). - If it helps, you may assume no inlining is taking place (an unrealistic assumption perhaps).
The answer is that it cannot.
Aside from all the non-portable details of how the call stack is implemented on different systems, suppose
foogets inlined intobar. 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
barsomewhere. 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. Eitherbaror the caller ofbar(or both) would need to co-operate with that, and agree withfoohow the "return value" is stored. So I assume that's not what you want. But if modifying the caller ofbaris 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 usingsetjmp/longjmpand with a fixed function signature instead of a template: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 thatbarmight have allocated some resource, or put some structure into a state that violates its invariants before callingfoo, with the intention of freeing that resource or restoring the invariant in the code following the call. So for general functionsbar, if you skip code inbarthen you might cause a memory leak or an invalid data state. The only way to avoid this in general, regardless of what is inbar, is to allow the rest ofbarto run. Of course ifbaris written in C++ with the expectation thatfoomight 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.