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
foo
gets 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
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
. Eitherbar
or the caller ofbar
(or both) would need to co-operate with that, and agree withfoo
how the "return value" is stored. So I assume that's not what you want. But if modifying the caller ofbar
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 usingsetjmp
/longjmp
and 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 thatbar
might 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 inbar
then 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 ofbar
to run. Of course ifbar
is written in C++ with the expectation thatfoo
might throw, then it will have used RAII for the cleanup code and it will run when you throw.longjmp
ing over adestructor has undefined behavior, though, so you have to decide before you start whether you're dealing with C++ or with C.