tir, 06.05.2003 kl. 20.23 skrev Gregory M. Turner:
On Monday 05 May 2003 07:28 pm, Ove Kaaven wrote:
tir, 06.05.2003 kl. 01.01 skrev Alexandre Julliard:
Ove Kaaven ovek@arcticnet.no writes:
Hmm. That could be solved by making the try block a nested function too, but I suppose that would bring some overhead...
Even ignoring the overhead, I can't think of a way to declare that function with the right return type. But maybe I missed something...
Hmm, true. I thought it might be possible to do some magic like typeof(func()), but then you'd need to know the name of the function, and I can't seem to find a gcc builtin that'll retrieve a reference to the current function (or its return type). Anyone else have any ideas? (No, __FUNCTION__ is a string, so it's no good.)
hmm, that sucks... there are some fancy __builtin_apply and __builtin_return thingys in gcc, not sure if those would help or not, they look like a bit of a research project in-and-of-themselves.
Of course, by using nested functions, this trick would limit our implementation to gcc, no g++.
Maybe this particular implementation, but C++ has other mechanisms that can be exploited. It might even be possible to bolt it on C++ native exceptions. If not, return could be caught by e.g. using a temporary object created in the try block which automatically unwinds the stack when it's destroyed unexpectedly. C++ is so rich that it shouldn't be hard to come up with such a technique, which is why I mostly concern myself with C-specific techniques right now, and don't care about they not working with g++; it should be completely acceptable to have one implementation if __cplusplus is defined and another if not, as long as it works, we don't have to limit ourselves to one implementation for both if it's impossible to have one that way.
Apart from the ugliness, what was wrong with hijacking the return address? It might be possible to put into the TEB any data you need that you expect will go out of scope by the time the hijacker-function gets invoked, I think.