rpc exception

[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 at 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++.  I figured out how VC++ does it: return does, 
indeed, become a fancy unwind/jump sequence.

The more I think about this one the more discouraged I become...  My idea of 
stealing the return adress on the stack is also no good: by the time our 
routine gets called, all the stack objects the __try {} block wants to refer 
to are gone.

There might be some really clever trick involving manually creating simulated 
stack frames, but I think it would require looking at data on the stack which 
is deallocated...  FWIW, it appears that vc++ does engage in some cheating of 
a similar nature, violating the "Thou shalt not look beyond the top of the 
stack" commandment.

btw ReactOS has a gcc patch for this:

http://reactos.wox.org/index.php?page=gccseh

they document several limitations there, so they aren't 100% done either, and 
obviously, requiring compiler patches to build wine isn't going to improve 
portability ;)

I think we have about three choices:

1) implement some really, really, really agressive stack mangling, and stick 
with macros somehow.

2) implement a parser/generator of some kind to do it ourselves

3) focus on convincing the gcc dev's to put it in, and only use the feature in 
wine if it's built into the compiler.

I don't like #3 and implementing #1 is looking pretty grim.

#1: so far nobody has thought of a way to do it; it's a dream, not a plan.
The possibilities we have explored, so far, would fail in g++ due to nested 
functions, and break various other language features they aren't supposed to.

#3: not portable, and therefore not generally usable in wine.

That leaves #2.  #2 could solve it for wine, ReactOS, anybody who wants it, 
really.  There are obviously certain hassles with another layer of parsing, 
like slower compiles, making sure we don't break debugging, actually 
implementing it, etc.

But I'm beginning to believe Alexandre that #1 is impossible (or at least 
beyond the capabilities of my imagination) without more expressive power at 
the language level.

-- 
"Security is mostly superstition. It does not exist in nature,
nor do the children of men as a whole experience it. Avoiding
danger is no safer in the long run than outright exposure. Life is
either a daring adventure, or nothing. To keep our faces toward
change and behave like free spirits in the presence of fate is
strength undefeatable." --Helen Keller

gmt